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About This Guide 


Purpose 
This guide provides: 


¢ Planning and implementation instructions 
* Service overviews 


¢ Links to detailed information in other service-specific guides. 





IMPORTANT: This book contains information for NetWare 6.5 SP8 and Novell Open Enterprise 
Server 2 SP1 Linux. For the latest information about using services on Linux, see the Novell Open 
Enterprise Server 2 SP2 Linux or later versions of the OES 2 SP2: Planning and Implementation 
Guide. 





Audience 
This guide is designed to help network administrators 


* Understand Open Enterprise Server 2 services prior to installing them. 
* Make pre-installation planning decisions. 
* Understand installation options for each platform. 


* Implement the services after they are installed. 


Feedback 


We want to hear your comments and suggestions about this manual and the other documentation 
included with OES 2. Please use the User Comments feature at the bottom of each page of the online 
documentation, or go to www.novell.com/documentation/feedback.html and enter your comments 
there. 


Documentation Updates 


Changes to this guide are summarized in a Documentation Updates appendix at the end of this 
guide. The lack of such an appendix indicates that no changes have been made since the initial 
product release. 


Additional documentation is also found on the NetWare 6.5 SP8 Documentation Web site (http:// 
www.novell.com/documentation/nw65). 


Additional Documentation 


The OES 2 SP2: Lab Guide for Linux and Virtualized NetWare is the hands-on counterpart to this 
guide and helps network administrators: 


* Setup a basic lab with an OES 2 Linux server, a virtualized NetWare? server, a test tree, and 
user objects that represent the different types of users in OES 2. 
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* Use the exercises in the guide to explore how OES 2 services work. 
* Continue exploring to gain a sound understanding of how OES 2 can benefit their organization. 


Additional Linux documentation is also found on the OES 2 Documentation Web site (http:// 
www.novell.com/documentation/oes2). 


Documentation Conventions 


The terms OES 2 and OES 2 SP1 are both used in this guide. Generally, OES 2 SP1 is used to 
differentiate something that is new or changed for the SP1 release of OES 2. Unless otherwise 
indicated, all statements that refer to OES 2 also apply to OES 2 SPI. 


In this documentation, a greater-than symbol (>) is used to separate actions within a step and items 
within a cross-reference path. 


A trademark symbol (E 7M, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party 
trademark. 


When a single pathname can be written with a backslash for some platforms, or a forward slash for 
other platforms, the pathname is presented with a forward slash to reflect the Linux* convention. 
Users of platforms that require a backslash, such as NetWare, should use backslashes as required by 
the software. 
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What's New 


This section summarizes the new features for each release of Novell? Open Enterprise Server (OES) 
2. 


* Section 1.1, “New in OES 2 SP1,” on page 15 
* Section 1.2, “New in OES 2 (Initial Release)," on page 19 


1.1 New in OES 2 SP1 


¢ Section 1.1.1, “Links to What's New Sections,” on page 15 
* Section 1.1.2, “Other New Features and Changes,” on page 17 


1.1.1 Links to What's New Sections 


The following table provides links to the What’s New sections in the documentation for all OES 2 
products. 


Table 1-1 What's New 


Product Link to What's New Section 


Archive and Version Services 2.1 Linux Administration Guide 


NetWare Administration Guide 


User Guide 
DHCP Linux Administration Guide 
Distributed File Services Administration Guide 
DNS Linux Administration Guide 
Domain Services for Windows Administration Guide 
Dynamic Storage Technology Administration Guide 
Identity Manager 3.6 Getting Started Guide (http://www.novell.com/ 


documentation/idm36/idm install/data/ 
be1l5dw.html) 


iManager 2.7 Administration Guide 
Installation Linux Installation Guide 
NetWare Installation Guide 
iPrint Linux Administration Guide 
NetWare Administration Guide 
Licensing (NetWare) Administration Guide 


Migration Tool Administration Guide 
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Product Link to What's New Section 


Native File Access Protocols Administration Guide 
NCP Server for OES 2 Linux Administration Guide 
NetStorage Linux Administration Guide 


NetWare Administration Guide 
Novell AFP Administration Guide 

Comparing the NetWare and Linux Solutions 
Novell CIFS Administration Guide 

Comparing the NetWare and Linux Solutions 
Novell Client™ Linux 

Windows XP/2003 Administration Guide 


Windows Vista* Administration Guide 


Novell Cluster Services™ (High Availability) Administration Guide 
Novell iFolder® 3.7 Administration Guide 

User Guide 
Novell Remote Manager Linux Administration Guide 


NetWare Administration Guide 


Novell Storage Services (NSS) Administration Guide 
Nsure® Audit Administration Guide 
OES 2 Linux Installation Guide 
NetWare 6.5 SP8 Installation Guide 


Memory Management Administration Guide 


Server OS Administration Guide 


OpenWBEM Administration Guide 
QuickFinder™ 5 Administration Guide 
RConsoleJ (NetWare) Administration Guide 
Samba (Linux) Administration Guide 
Server Health Monitoring This is now available in various Novell Remote 


Manager dialog boxes on both platforms. 


For more information, see “Health Monitoring 
Services” on page 85. 


Shadow Volumes See “Overview of Dynamic Storage Technology” in 
the OES 2 SP2: Dynamic Storage Technology 
Administration Guide. 


Storage Management Services (SMS) Administration Guide 
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Product Link to What's New Section 


Virtualization (Xen*) Virtualization Overview 


1.1.2 Other New Features and Changes 


+ “YaST Install Changes" on page 17 

* “Novell AFP” on page 17 

* “Novell CIFS" on page 18 

* "Novell Domain Services for Windows" on page 18 


* "Migration Tool" on page 18 


YaST Install Changes 


The default behavior of the option to use eDirectory™ certificates for HTTPS services has changed 
in OES 2 SPI. 


In OES 2, eDirectory certificates were only used by default if you were installing a new server. 


In OES 2 SP1, eDirectory certificates are used by default in all installation and upgrade scenarios, 
except when you are upgrading to SP1 from OES 2. For an upgrade, the option that you selected for 
the initial installation is retained. 


For a brief summary of what happens in each scenario, see Table 22-2 on page 238. 


Novell AFP 
Novell? AFP is now available on the Linux platform to provide feature parity with NetWare®. 
* Support for AFP v3.1 and AFP v3.2, providing network file services for Mac* OS X* and 
classic Mac OS workstations 
* Support for Universal Password greater than 8 characters 
* Integration with Novell eDirectory 
* Integration with the Novell Storage Services™ (NSS) file system 
* Support for Unicode* filenames 
* Integration with the Novell Trustee Model for file access 
* Support for regular eDirectory users (no LUM required) 
* Cross-protocol file locking with NCP™ 
Novell AFP also offers the following features not available for NetWare: 
* DHX authentication mechanism: Provides a secure way to transport passwords of up to 64 
characters to the server. 


* Management: You can use iManager to administer and configure the AFP server on OES 2 
Linux. iManager support for AFP on NetWare is unchanged and includes only starting and 
stopping the server. 


* Auditing: You can audit the AFP server to check on the authentication process and any 
changes that occur to the configuration parameters of the server. 
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For more information, see the OES 2 SP2: Novell AFP For Linux Administration Guide. 


Novell CIFS 


Novell CIFS is now available on Linux to provide feature parity with the existing NetWare release. 
It offers the following features: 

* Support for Windows* 2000, XP, 2003, and Windows Vista* 32-bit 

* Support for Universal Password greater than 8 characters 

* Support for NTLMvI authentication mode 

* Integration with Novell eDirectory 

* Integration with the Novell Storage Services (NSS) file system 

* Support for Unicode filenames 

* Integration with the Novell Trustee Model for file access 

* Support for regular eDirectory users (no LUM required) 


* Cross-protocol file locking is planned for a future release 


For more information, see the OES 2 SP2: Novell CIFS for Linux Administration Guide. 


Novell Domain Services for Windows 


This service creates seamless cross-authentication capabilities between Microsoft* Active 
Directory* on Windows servers and Novell eDirectory on OES 2 SP1 Linux servers, and offers the 
following functionality: 


* Administrators with Windows networking environments can set up one or more “virtual” 
Active Directory domains in an eDirectory tree. 


* Administrators can manage users and groups through MMC or iManager. 


* eDirectory users can authenticate to the virtual domain from a Windows workstation without 
the Novell Client™ for Windows being installed. 


* eDirectory users can also access file services on 
* Novell Storage Services (NSS) volumes on Linux servers by using Samba shares. 
* NTFS files on Windows servers that use CIFS shares. 


* Shares in trusted Active Directory forests. 


For more information, see the OES 2 SP2: Domain Services for Windows Administration Guide. 


Migration Tool 


The new OES 2 SP1 Migration Tool uses a plug-in architecture and comprises multiple Linux 
command line utilities and a GUI wrapper. 


The Migration Tool supports: 


* Asingle, enhanced GUI interface for migrating all OES services 
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* Service migrations from either a single source server or multiple source servers (consolidation) 
to a target server. 


* Transfer ID (server ID swap) migrations—transferring the services and identity from one 
server to another server. 


For more information, see the OES 2 SP2: Migration Tool Administration Guide. 


1.2 New in OES 2 (Initial Release) 


Novell Open Enterprise Server 2 included the following major features and enhancements that were 
not included in OES 1. All features are retained in SP1 unless otherwise noted in Section 1.1, “New 
in OES 2 SP1,” on page 15. 


* Section 1.2.1, “Dynamic Storage Technology,” on page 19 
* Section 1.2.2, "OES 2 Migration Tools," on page 19 
* Section 1.2.3, “Xen Virtualization Technology,” on page 19 


1.2.1 Dynamic Storage Technology 


OES 2 introduces Novell Dynamic Storage Technology, a unique storage solution that lets you 
combine a primary file tree and a shadow file tree so that they appear to NCP and Samba/CIFS users 
as one file tree. The primary and shadow trees can be located on different file systems, different 
servers, or even different types of storage. 


This lets you manage storage costs in new and efficient ways that were not previously possible. 


For more information, see the related sections in Chapter 13, "Storage and File Systems,” on 
page 125 and the OES 2 SP2: Dynamic Storage Technology Administration Guide. 


1.2.2 OES 2 Migration Tools 


In addition to the legacy Server Consolidation and Migration Toolkit, OES 2 includes new migration 
tools for migrating data and services from NetWare to OES 2 Linux. 


For more information, see Chapter 8, “Migrating and Consolidating Existing Servers and Data,” on 


page 73. 


1.2.3 Xen Virtualization Technology 


Both OES 2 Linux and OES 2 NetWare can run in virtual machines on either an OES 2 Linux or a 
SUSE® Linux Enterprise Server 10 SP1 or later server. This is especially valuable to those 
organizations that are deploying new hardware that doesn’t run NetWare as a physical installation. 


For more information, see Chapter 9, “Virtualization in OES 2,” on page 75. 
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Welcome to Open Enterprise 
Server 2 


Novell® Open Enterprise Server 2 (OES 2) includes all the network services that organizations 
traditionally expect from Novell. 


Figure 2-1 OES 2 Overview 


OES 2 SP1 Linux 


is 


INoVellsSenilees 
* AFP e CIFS * Management Tools 
* Backup (SMS) * FTP e iPrint 
* Clustering (High Availability) + iFolder 3.x * QuickFinder 
* DNS/DHCP * NetStorage e Novell Storage Services (NSS) 
* eDirectory * Novell Client Access 


running 
on 


L 


= 
- 


SUSE Linux Enterprise Server 10 SP2 








NOTE: For a list of OES 2 services by platform, see Table 3-1, “Service Comparison Between 
NetWare 6.5 SP8 and OES 2 SP1 Linux,” on page 23. 
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Planning Your OES 2 
Implementation 


As you plan which services to install on which Open Enterprise Server platform, you probably have 
a number of questions. The following sections are designed to help answer your questions and alert 
you to the steps you should follow for a successful OES implementation. 


* 


* 


* 


Section 3.1, “What Services Are Included in OES 2?,” on page 23 

Section 3.2, “Which Services Do I Need?,” on page 30 

Section 3.3, “Exploring OES 2 services,” on page 30 

Section 3.4, “Which OES 2 Platform Is Best for My Services?,” on page 31 
Section 3.5, “Plan for eDirectory,” on page 31 

Section 3.6, “Prepare Your Existing eDirectory Tree for OES 2,” on page 32 
Section 3.7, “Identify a Purpose for Each Server,” on page 32 

Section 3.8, “Understand Server Requirements,” on page 32 

Section 3.9, “Understand User Restrictions and Linux User Management,” on page 33 
Section 3.10, “Caveats to Consider Before You Install,” on page 33 

Section 3.11, “Consider Coexistence and Migration Issues,” on page 44 
Section 3.12, “Understand Your Installation Options,” on page 44 


Section 3.13, “eGuide, [Folder 2, and Virtual Office Are Still Available on Netware,” on 
page 48 


3.1 What Services Are Included in OES 2? 


Table 3-1 summarizes the services and technology support available on each platform and the 
differences in the way these services are provided. 


Although extensive, this list is not exhaustive. If you are interested in a service or technology not 
listed, or for documentation for listed services, see the OES Documentation Web site (http:// 
www.novell.com/documentation/oes2). 


Table 3-1 Service Comparison Between NetWare 6.5 SP8 and OES 2 SP1 Linux 


Service NetWare 6.5SP8 OES 2 Linux Platform Differences / Migration Issues 


Access Control Lists Yes Yes In combination with NCP™ Server, Linux 


supports the Novell® trustee model for file 
access on NSS volumes and NCP volumes 





on Linux. 
AFP (Apple* File Yes - NFAP Yes - Novell AFP services on NetWare and OES Linux 
Protocol) AFP are proprietary and tightly integrated with 


eDirectory™ and Novell Storage Services 
(NSS). 
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Service 


Apache Web Server 


NetWare 6.5 SP8 


Yes - NetWare® 
port of open 
source product 


OES 2 Linux 


Yes - Standard 


Linux 


Platform Differences / Migration Issues 


Administration Instance vs. Public Instance 
on NetWare (http://www.novell.com/ 
documentation/oes2/web_apache_nw/data/ 
aipcu6x.html#aipcu6x). 


What's Different about Apache on NetWare 
(http:/Awww.novell.com/documentation/ 
oes2/web_apache_nw/data/ail8hvj.html) . 





Archive and Version 
Services (Novell) 


Yes 


Yes 


Setup varies slightly, but there are no 
functional differences. 





Backup (SMS) 


* SMS 
* NSS-Xattr 


Yes 


Yes 


SMS provides backup applications with a 
framework to develop complete backup and 
restore solutions. For information, see the 
NW 6.5 SP8: Storage Management 
Services Administration Guide. 


NSS provides extended attribute handling 
options for NSS on Linux. For information, 
see "Using Extended Attributes (xAttr) 
Commands (Linux)" in the NW 6.5 SP8: 
NSS File System Administration Guide. 





CIFS (Windows File 
Services) 


Yes - NFAP 


Yes - Novell 
CIFS 


and 


Novell Samba 


Both NFAP and Novell CIFS are Novell 
proprietary and tightly integrated with 
eDirectory and Novell Storage Services 
(NSS). For a feature comparison by 
platform, see "Comparing CIFS on NetWare 
and CIFS on Linux” in the OES 2 SP2: 
Novell CIFS for Linux Administration Guide. 


Samba is an open source product 
distributed with SUSE® Linux Enterprise 
Server (SLES). 


Novell Samba is enhanced by Novell with 
configuration settings for eDirectory LDAP 
authentication via Linux User Management 
(LUM). Novell Samba is not tightly 
integrated with NSS on Linux and works 
with any of the supported file systems. 





Clustering 


Yes 


Yes 
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"Product Features" in the OES 2 SP2: 
Novell Cluster Services 1.8.7 for Linux 
Administration Guide. 


"Product Features" in the NW6.5 SP8: 
Novell Cluster Services 1.8.5 Administration 
Guide. 


Service NetWare 6.5SP8 OES 2 Linux 


DFS (Novell Distributed Yes Yes 
File Services) 


Platform Differences / Migration Issues 


In combination with NCP Server, DFS 
supports junctions and junction targets for 
NSS volumes on Linux and NetWare. DFS 
also supports junction targets for NCP 
volumes on non-NSS file systems such as 
Reiser and Ext3. The VLDB command 
offers additional options to manage entries 
in the VLDB for NCP volumes. 





DHCP Yes Yes 


For a comparison between what is available 
on OES 2 Linux and NetWare, see 

Section 12.2.2, “DHCP Differences 
Between NetWare and OES 2 Linux,” on 
page 103. 


To plan your DHCP implementations, see 
“Planning a DHCP Strategy” in the OES 2 
SP2: Novell DNS/DHCP Administration 
Guide for Linux and “Planning a DHCP 
Strategy” in the NW 6.5 SP8: Novell DNS/ 
DHCP Services Administration Guide. 





DNS Yes Yes 


For a comparison between what is available 
on OES 2 Linux and NetWare, see 

Section 12.2.1, *DNS Differences Between 
NetWare and OES 2 Linux," on page 102. 


See "Planning a DNS Strategy" in the OES 
2 SP2: Novell DNS/DHCP Administration 
Guide for Linux and "Planning a DNS 
Strategy" in the NW 6.5 SP8: Novell DNS/ 
DHCP Services Administration Guide. 





Dynamic Storage No Yes 
Technology 


DST runs on OES 2 Linux. An NSS volume 
on NetWare is supported only as the 
secondary volume in a shadow pair. When 
using DST in a cluster, each of the NSS 
volumes in a shadow pair must reside on 
OES 2 Linux. DST also supports NCP 
volumes as shadow pairs and Linux POSIX* 
volumes as shadow pairs. 





eDirectory 8.8 Yes Yes 


No functional differences. 





eDirectory Certificate Yes Yes 
Server 


No functional differences. 





eGuide (White Pages) Yes No 


This functionality is now part of the Identity 
Manager 3.6 User Application. For more 
information, see the Identity Manager 3.6 
Documentation Web Site. (http:// 
www.novell.com/documentation/idm36/ 
index.html). 
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Service NetWare 6.5SP8 OES 2 Linux Platform Differences / Migration Issues 


FTP Server Yes Yes Support for eDirectory LDAP authentication 
has been added to PureFTP on OES 2 
Linux. The FTP/SFTP gateway available on 
NetWare is not currently available on Linux. 
See Section 17.1.2, “FTP Services,” on 
page 188. 


See “Features of the NetWare FTP Server” 
in the NW 6.5 SP8: Novell FTP 
Administration Guide. 





Health Monitoring Yes Yes The Health Monitoring Server, which was 
Services included in OES 1, has been removed in 
OES 2. 


This is now available in various Novell 
Remote Manager dialog boxes on both 
platforms. 


For more information, see “Health 
Monitoring Services” on page 85. 


Identity Manager 3.5 Yes Yes No functional differences. 
Bundle Edition 





iPrint Yes Yes See "Overview" in the OES 2 SP2: iPrint for 
Linux Administration Guide, and "Overview" 
in the NW 6.5 SP8: iPrint Administration 
Guide. 





IPX™ (Internetwork Yes No Novell has no plans to port IPX to OES 
Packet Exchange™) Linux. 
from Novell 





iSCSI Yes Yes The iSCSI target for Linux does not support 
eDirectory access controls like the NetWare 
target does. Nor is the iSCSI initiator or 
target in OES 2 Linux integrated with 
NetWare Remote Manager management. 
You use YaST management tools instead. 


On the other hand, the iSCSI 
implementation for Linux is newer and 
performs better. 


See Linux-iSCSI Project on the Web (http:// 
linux-iscsi.sourceforge.net). 


See "Overview" in the NW 6.5 SP8: iSCSI 
1.1.3 Administration Guide. 





LDAP Server for Yes Yes No functional differences. 
eDirectory 





Multipath Device Yes Yes NetWare uses NSS multipath I/O. Linux 

Management uses Device Mapper - Multipath that runs 
underneath other device management 
services. 
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Service 


NetWare 6.5 SP8 OES 2 Linux 


Platform Differences / Migration Issues 





























MySQL* Yes - NetWare Yes - Standard See MySQL.com on the Web (http:// 
port of open Linux www.mysql.com). 
source product 
See “Overview: MySQL’ in the NW 6.5 SP8: 
Novell MySQL Administration Guide. 

NCP Volumes No Yes NCP Server on Linux supports creating 
NCP volumes on Linux POSIX file systems 
such as Reiser and Ext3. 

For information, see "Managing NCP 
Volumes" in the OES 2 SP2: NCP Server for 
Linux Administration Guide. 

NCP Server Yes Yes NCP services are native to OES NetWare 
and NSS volumes; to have NCP services on 
OES Linux, the NCP Server must be 
installed. 

See “Benefits of NCP Server” in the OES 2 
SP2: NCP Server for Linux Administration 
Guide. 

NetStorage Yes Yes NetStorage on Linux offers connectivity to 
storage locations through the CIFS, NCP, 
and SSH protocols. NetWare uses only 
NCP. 

These and other differences are 
summarized in “NetStorage” on page 190. 

NetWare Traditional Yes No Novell has no plans to port the NetWare 

File System Traditional File System to Linux. 

NetWare Traditional Yes N/A 

Volumes 

NFS Yes - NFAP Yes - native to For NetWare, see “Working with UNIX 

Linux Machines’ in the NW 6.5 SP8: AFP, CIFS, 
and NFS (NFAP) Administration Guide. 

NICI (Novell Yes Yes No functional differences. 

International 

Cryptography 

Infrastructure) 

NMAS™ (Novell Yes Yes No functional differences. 

Modular Authentication 

Services) 

Novell Audit Yes No Novell Audit is not included with OES Linux. 
However, the Novell Audit 2.0 Starter pack 
is available for download at no cost on 
Novell.com (http://www.novell.com/ 
downloads). 

Novell Client™ for Yes Yes Novell Client connectivity to OES 2 Linux 


Windows and Linux 
support 


requires that the NCP Server be installed. 
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Service NetWare 6.5SP8 OES 2 Linux Platform Differences / Migration Issues 


Novell Cluster Yes Yes See "Product Features" in the OES 2 SP2: 
Services ™ Novell Cluster Services 1.8.7 for Linux 
Administration Guide. 


See "Product Features" in the NW6.5 SP8: 
Novell Cluster Services 1.8.5 Administration 
Guide. 





Novell iFolder® 2.x Yes No For migration information, see “Migrating 
iFolder 2.x” in the OES 2 SP2: Migration 
Tool Administration Guide 











Novell iFolder 3.7 No Yes OES 2 SP1 Linux includes Linux, 
Macintosh*, and Windows clients. 

Novell Licensing Yes No See Section 4.5.4, "DES 2 Linux Doesn't 

Services Support NLS," on page 55. 

NSS (Novell Storage Yes Yes Most NSS services are available on both 

Services™) platforms. For a list of NSS features that are 


not used on Linux, see “Cross-Platform 
Issues for NSS’ in the NW 6.5 SP8: NSS 
File System Administration Guide. 





NTPv3 Yes Yes The ntpd.conf file on NetWare can 
replace an OES Linux server’s NTP 
configuration file without modification. 





OpenSSH Yes Yes Netware includes a port of the open source 
product. Linux includes the open source 
product itself. 


See “Functions Unique to the NetWare 
Platform” in the NW 6.5 SP8: OpenSSH 
Administration Guide. 





PAM (Pluggable No Yes PAM is a Linux service that Novell 
Authentication leverages to provide eDirectory 
Modules) authentication. eDirectory authentication is 


native on NetWare. 





Pervasive.SQL* Yes No Pervasive.SQL is available for Linux from 
the Web (http://www.pervasive.com/ 
support/technical/online_manuals.asp). 














PKI (Public Key Yes Yes No functional differences. 
Infrastructure) 

Printing Yes Yes See iPrint. 

QuickFinder™ Yes Yes See Search. 

RADIUS Yes Yes See the information on forge.novell.com 


(http://forge.novell.com/modules/xfmod/ 
project/?edirfreeradius). 
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Service NetWare 6.5SP8 OES 2 Linux 


Samba No Yes 


Platform Differences / Migration Issues 


Samba is an open source technology 
available on OES Linux. Novell provides 
automatic configuration for authentication 
through eDirectory. For more information, 
see the OES2 SP2: Samba Administration 
Guide. 


OES NetWare provides CIFS connectivity 
through NFAP. See Section 17.1.3, “Native 
File Access Protocols,” on page 188. 





Search (QuickFinder) Yes Yes 


When indexing a file system, the 
QuickFinder engine indexes only what it has 
rights to see. 


On NetWare, it has full access to all 
mounted volumes. On Linux, it has rights to 
only the files that the noviwww user in the 
www group has rights to see. 


For more information, see “Security 
Considerations for QuickFinder Server” and 
“Generating an Index For a Linux-Mounted 
NSS Volume" in the NW 6.5 SP8 Novell 
QuickFinder Server 5.0 Administration 
Guide. 





SLP Yes - Novell 
SLP 


Yes - OpenSLP 


For OES 2 Linux, see “SLP Services in the 
Network" (http://www.novell.com/ 
documentation/sles10/book sle reference/ 
data/cha slp.html) in the SUSE Linux 
Enterprise Server 10 SP3 Installation and 
Administration Guide (http:// 
www.novell.com/documentation/sles10/ 
book sle reference/data/ 

book sle reference.html) and 
"Implementing the Service Location 
Protocol" (http://www.novell.com/ 
documentation/edir87/edir87/data/ 
a2iiimc.html). 


NetWare uses Novell SLP, which provides 
synchronization between Directory Agents 
(DAs) that are in the same eDirectory 
context. This provides service information 
beyond the local network. 


Novell SLP is not available on Linux. 
OpenSLP on Linux is not customized to 
provide DA synchronization. Therefore, DA 
synchronization is only available for 
eDirectory on NetWare. 





Software RAIDS (NSS Yes (0, 1,5, 10, Yes (0, 1, 5) 
volumes) 15) 


See "Understanding Software RAID 
Devices" in the NW 6.5 SP8: NSS File 
System Administration Guide. 
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Service 


Storage Management 
Services™ (SMS) 


NetWare 6.5 SP8 


Yes 


OES 2 Linux 


Yes 


Platform Differences / Migration Issues 


No functional differences, except that the 
SBCON backup engine is not supported on 
Linux. 


The nbackup engine is available for 
exploring SMS capabilities, but in a 
production environment, you should use a 
third-party, full-featured backup engine. 





TCP/IP 


Yes 


Yes 


No functional differences. 





Timesync NLM™ 


Yes 


No 


Timesync will not be ported to Linux. 
However, NTPv3 is available on both Linux 
and NetWare. 


See “Time Services” on page 104. 





Tomcat 


Yes 


Yes 


NetWare includes Tomcat 4 and a Tomcat 5 
servlet container for iManager 2.7. OES 2 
Linux includes Tomcat 5. There is no impact 
to any of the OES 2 administration tools, 
which are tested and supported on both 
platforms. 


See “Administration Instance vs. Public 
Instance on NetWare” (http:// 
www.novell.com/documentation/oes2/ 
web_tomcat_nw/data/ahdyran.html) 





Virtual Office 
(Collaboration) 


Yes 


No 


Virtual Office has been replaced by Novell 
Teaming + Conferencing. A separate 
purchase is required. For more information, 
see the Novell Teaming + Conferencing 
Web Site (http://www.novell.com/products/ 
teaming/index.html). 





WAN Traffic Manager 


Yes 


No 





Xen Virtualization 
Guest 


Yes 


Yes 


OES 2 NetWare (NetWare 6.5 SP 7) can 
run on a paravirtualized machine. OES 2 
Linux can run on a paravirtualized machine 
or fully virtualized machine. 





Xen Virtualization Host 
Server 


N/A 


Yes 


3.2 Which Services Do | Need? 


We recommend that you review the brief overviews included at the beginning of each service 
section in this guide to get a full picture of the solutions that OES 2 offers. It is not uncommon that 
administrators discover capabilities in OES that they didn’t know existed. 


3.3 Exploring OES 2 services 


We also recommend that you explore the services by following the step-by-step instructions 
provided in the OES 2 SP2: Lab Guide for Linux and Virtualized NetWare. 
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3.4 Which OES 2 Platform Is Best for My 


Services? 


You can deploy OES 2 SPI services on either 


* OES 2 NetWare (NetWare 6.5 SP8) or later 
* SUSE Linux Enterprise Server 10 SP2 or later 


There are, of course, differences in the way OES provides services on Linux and NetWare (see 
Section 3.1, “What Services Are Included in OES 2?,” on page 23). 


To better assess which OES platform can best meet your network service needs, consider the 


following: 


* Differences in the platform service offerings that are outlined in Table 3-1 on page 23. 


* Inherent Linux and NetWare strengths that are summarized in Table 3-2 on page 31. 


Table 3-2 Platform Comparison 


Brief description 


OES 2 NetWare 


The Novell award-winning 
network-optimized operating 
system. 


SUSE Linux Enterprise Server 10 


The Novell award-winning Linux 
operating system. 





Industry-recognized strengths 


* Reliability 
* Scalability 


* Security 


* Open application 
environment 


* Flexibility 
* Versatility 





Business value propositions 


NetWare excels when the user 
population and management 
burden is highly distributed: 


* Increases network 
availability. 


* Optimizes manageability. 


* Enhances user productivity. 


* Runs Apache, Tomcat, 
MySQL, and other open 
source applications. 


3.5 Plan for eDirectory 


eDirectory is the heart of OES network services and security. 


If you are installing into an existing tree, be sure you understand the information in Section 14.2.3, 


“eDirectory Coexistence and Migration," on page 145. 


SLES 10 is well suited as an 
application server running Linux- 
based solutions: 


* Runs thousands of 
programs available from the 
open source community. 


* Delivers OES file and print 
services. 


* Hosts open source Web 
Servers, proxy servers, and 
mail servers. 
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If you are creating a new eDirectory tree on your network, you must do some additional planning 
before you install the first server into the tree. The first server is important for two reasons: 
* You create the basic eDirectory tree structure during the first installation 


¢ The first server permanently hosts the Certificate Authority for your organization 
To ensure that your eDirectory tree meets your needs, take time to plan the following: 


* Structure of the eDirectory tree: A well-designed tree provides containers for servers, users, 
printers, etc. It is also optimized for efficient data transfer between geographically dispersed 
locations. For more information, see “Designing Your Novell eDirectory Network” in the 
Novell eDirectory 8.8 Administration Guide. 


¢ Time synchronization: eDirectory requires that all OES 2 servers, both NetWare and Linux, 
be time synchronized. For more information, see Chapter 12.3, “Time Services,” on page 104. 


¢ Partitions and replicas: eDirectory allows the tree to be partitioned for scalability. Replicas 
(copies) of the partitions provide fault tolerance within the tree. The first three servers installed 
into an eDirectory tree automatically receive replicas of the tree’s root partition. You might 
want to create additional partitions and replicas. For more information, see “Managing 
Partitions and Replicas” in the Novell eDirectory 8.8 Administration Guide. 


For information on these and other eDirectory planning tasks, see the Novell eDirectory 8.8 
Administration Guide. 


The OES 2 SP2: Lab Guide for Linux and Virtualized NetWare provides a basic introduction to 
creating container objects as well as Group and User objects in eDirectory. 


3.6 Prepare Your Existing eDirectory Tree for 
OES 2 


If you are installing OES 2 into an existing tree, you must use Deployment Manager (located on the 
NetWare 6.5 SP8 DVD) to see whether your tree requires any updates. 


For instructions on running Deployment Manager, see “Using Deployment Manager” in the NW65 
SP6: Installation Guide. 


3.7 Identify a Purpose for Each Server 


Large networks usually have one or more servers dedicated to providing a single network service. 
For example, one or more servers might be designated to provide Novell iFolder file services to 
network users while other servers provide iPrint printing services for the same users. 


For smaller organizations, it is often not practical or cost effective to dedicate servers to providing a 
single service. For example, the same server might provide both file and print services to network 
users. 


Prior to installing a new server on your network, you should identify the service or services that it 
will provide. 


3.8 Understand Server Requirements 


OES 2 Linux and OES 2 NetWare both have specific hardware and software requirements. 
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Prior to installing OES, make sure your server machine and network environment meet the 
requirements outlined in the following sections: 


+ OES 2 Linux Server (Physical): “Preparing to Install OES 2 SP2” in the OES 2 SP2: 


Installation Guide. 


+ OES 2 Linux Server (Virtual): “System Requirements” in the OES 2 SP2: Installation 


Guide. 


* OES 2 NetWare Server (Physical): “Meeting Hardware and Software Requirements” in the 


NW65 SP8: Installation Guide. 


+ OES 2 NetWare Server (Virtual): “Planning for NetWare VM Guest Servers” in the OES 2 


SP2: Installation Guide. 


3.9 Understand User Restrictions and Linux User 
Management 
If you plan to use Linux User Management, be sure you understand the security implications before 


you accept the default PAM-enabled service settings. The implications are explained in 
Section 21.2.2, “User Restrictions: Some OES 2 Linux Limitations,” on page 230. 


3.10 Caveats to Consider Before You Install 





IMPORTANT: As support packs are released, there are sometimes new caveats identified. Be sure 
to always check the OES Readme (http://www.novell.com/documentation/oes2/oes readme/data/ 
readme.html) for items specific to each support pack. 





This section discusses the following installation/migration caveats: 


* 


* 


Section 3.10.1, *AFP File Locking Requires Samba," on page 34 


Section 3.10.2, *Adding a Linux Node to a Cluster Ends Adding More NetWare Nodes," on 
page 34 


Section 3.10.3, “Do Not Create Local (POSIX) Users," on page 34 

Section 3.10.4, “Samba Enabling Disables SSH Access," on page 34 

Section 3.10.5, *Cluster Upgrades Must Be Planned Before Installing OES 2," on page 34 
Section 3.10.6, *Follow the Instructions for Your Chosen Platforms," on page 35 

Section 3.10.7, *iFolder 3.7 Considerations,” on page 35 

Section 3.10.8, "Installing into an Existing eDirectory Tree," on page 35 

Section 3.10.9, *NetWare License Placement in the Tree," on page 36 

Section 3.10.10, *NetWare Licenses and OES 2 Linux Trees," on page 36 

Section 3.10.11, “NetWare 6.5 Servers Must Be Running SP3 or Later," on page 37 


Section 3.10.12, *If You've Ever Had OES 1 Linux Servers with LUM and NSS Installed," on 
page 37 


Section 3.10.13, *Novell Distributed Print Services Cannot Migrate to Linux," on page 41 
Section 3.10.14, *NSS Caveats," on page 41 


Section 3.10.15, “Unsupported Service Combinations,” on page 41 
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3.10.1 AFP File Locking Requires Samba 


Cross-protocol file locking between AFP and NCP connections on an OES 2 Linux server requires 
that you install Samba on the server, even though Samba file services cannot be run concurrently 
with AFP on the same server. (See “Novell AFP” on page 41.) For more information, see the OES 2 
SP2: Novell AFP For Linux Administration Guide 


3.10.2 Adding a Linux Node to a Cluster Ends Adding More 
NetWare Nodes 
After you add a Linux node to a cluster, you cannot add more NetWare nodes. For more information, 


see *Converting NetWare 6.5 Clusters to OES 2 Linux" in the OES 2 SP2: Novell Cluster Services 
1.8.7 for Linux Administration Guide. 


3.10.3 Do Not Create Local (POSIX) Users 


During the OES 2 Linux install you are prompted by the SLES portion of the install to create at least 
one user besides root and you are warned if you bypass the prompt. 


Creating local users is not recommended on OES 2 Linux servers because user management in OES 
2 is managed entirely in eDirectory. The only local user you need on the server is the root user. 
Creating other local users can, in fact, cause unnecessary confusion and result in service-access 
problems that are difficult to troubleshoot. 


eDirectory users are enabled for POSIX access through the Linux User Management (LUM) 
technology installed by default on every OES 2 Linux server. 


Also be aware that not all OES services require that users are LUM-enabled. Novell Client users, for 
example, can access NCP and NSS volumes on OES 2 Linux servers just as they do on NetWare 
without any additional configuration. 


For more information about this topic, see Section 15.2, “Linux User Management: Access to Linux 
for eDirectory Users," on page 153. 


3.10.4 Samba Enabling Disables SSH Access 


Enabling users for Samba automatically disables SSH access for them. However, this default 
configuration can be changed. For more information, see Section 11.4, "SSH Services on OES 2 
Linux," on page 96. 


3.10.5 Cluster Upgrades Must Be Planned Before Installing 
OES 2 


Because of differences between Novell Cluster Services on OES 2 NetWare and OES 2 Linux, there 
are important issues to consider before combining them into a mixed node cluster, as explained in 
the following sections. 


* "Service Failover in a Mixed Cluster" on page 35 


* “Working with Mixed Node Clusters" on page 35 
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Service Failover in a Mixed Cluster 


The only cluster-enabled service that can fail over cross-platform (run on either OES 2 Linux or 
OES 2 NetWare) is cluster-enabled NSS pools. All other services (iPrint, iFolder, etc.) can only fail 
over between servers that are the same platform. For example, an iPrint service that is running on an 
OES 2 Linux server can fail over to another OES 2 Linux server in the cluster, but the service cannot 
fail over to an OES 2 NetWare server. 


Working with Mixed Node Clusters 
The following points apply to working with mixed NetWare and OES Linux clusters: 
* You cannot uses EVMSGUI to create a Linux POSIX file system as a cluster resource until the 
entire cluster is migrated to Linux. 


* You cannot migrate or fail over a Linux POSIX file system cluster resource to a NetWare 
cluster node. 


* Only NSS pool cluster resources that are created on a NetWare cluster node can be failed over 
between Linux and NetWare nodes. 


* NetWare NSS to Linux NSS failover requires that the Linux node be configured for NSS and 
that the version of NSS supports the NSS media format and features being used by the NSS 
pool cluster resource. 


* The new NSS media format in OES 2 is not available for OES 1 SP2 Linux and earlier. After a 
volume has been upgraded to the new media format, you cannot fail it over to a node that is 
running OES 1 SP2 Linux or earlier. 


3.10.6 Follow the Instructions for Your Chosen Platforms 


Although installing OES 2 services on Linux or NetWare is a straightforward process, the 
installation processes are platform-specific, requiring different sets of media and different 
installation programs. 


3.10.7 iFolder 3.7 Considerations 


For best results, be sure you read and carefully follow the instructions in the Novell iFolder 3.8 
Administration Guide, starting with “Deploying iFolder Server .” This is especially critical if you 
plan to use NSS for your iFolder 3.8 data volume. 


3.10.8 Installing into an Existing eDirectory Tree 


Novell Support has reported a significant number of installation incidents related to eDirectory 
health and time synchronization. To avoid such problems, do the following prior to installing OES: 
* "Consider Coexistence and Migration Issues" on page 36 
* "Do Not Add OES to a Server That Is Already Running eDirectory" on page 36 
* "Be Sure That eDirectory Is Healthy" on page 36 
* "Be Sure That Network Time Is Synchronized" on page 36 
* "Be Sure that OpenSLP on OES 2 Linux Is Configured Properly" on page 36 
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Consider Coexistence and Migration Issues 


If you are installing a new OES 2 server into an existing eDirectory tree, be sure to read and follow 
the instructions in these sections: 


* “Preparing eDirectory for OES 2 SP2” in the OES 2 SP2: Installation Guide 
+ “Installing the Server into an Existing eDirectory Tree" in the NW65 SP8: Installation Guide. 


Do Not Add OES to a Server That Is Already Running eDirectory 


Although you can add OES to an existing SLES 10 server if needed, you cannot install OES on a 
SLES 10 server that is already running eDirectory. 


eDirectory must be installed in conjunction with the installation of OES services. 


Be Sure That eDirectory Is Healthy 

Review and follow the guidelines in “Keeping eDirectory Healthy” in the Novell eDirectory 8.8 
Administration Guide. 

Be Sure That Network Time Is Synchronized 


OES2 Linux and OES 2 NetWare servers can receive network time from either an existing 
eDirectory server or from an NTP time source. The critical point is that the entire tree must be 
synchronized to the same time source. For example, do not set your new OES 2 server to receive 
time from an NTP source unless the whole tree is synchronized to the same NTP source. 


For an in-depth explanation of OES time synchronization, see Chapter 12.3, “Time Services,” on 
page 104. 
Be Sure that OpenSLP on OES 2 Linux Is Configured Properly 


Novell SLP (NetWare) and OpenSLP (Linux) can coexist, but there are differences between the 
services that you should understand before deciding which to use or before changing your existing 
SLP service configuration. For more information, see Section 12.5, “SLP,” on page 116. 


3.10.9 NetWare License Placement in the Tree 


By default, NetWare licenses are installed in the same eDirectory container as NetWare servers. 
Because these licenses also apply to user connections, it is important to install them at or above the 
location of both servers and users. 


For example, if your tree has containers named SERVERS and USERS that are siblings in the tree, 
you should install the NetWare licenses in a parent or higher container of these two containers. 


3.10.10 NetWare Licenses and OES 2 Linux Trees 


OES 2 Linux doesn't use the traditional Novell Licensing Services (Section 4.5, “Licensing,” on 
page 54). As a result, OES Linux servers don't need a license container in eDirectory as part of the 
server installation. 
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Therefore, when the first NetWare server is installed in the tree, it needs to add a license container, 
and to do this it must have a Read/Write replica of eDirectory accessible on the server. If the 
NetWare server is either the second or third server installed in the tree, it automatically has a replica 
added. If not, a replica is not added, the license container cannot be created at install time, and a 
license cannot be installed. 


Unlicensed NetWare servers allow only two user connections. To be usable, therefore, the server 
needs the MLA license installed that is included on the NetWare installation media. For information 
about the MLA license, see “NetWare 6.5 SP8 Includes MLA License Files" in the NW 6.5 SP8: 
Licensing Services Administration Guide. 


To install the license, you must do the following: 


1 Install iManager on the NetWare server, or use iManager Workstation. 


You can do this during initial installation or later as described in “Installing iManager” in the 
Novell iManager 2.7 Installation Guide. 


2 Adda Read/Write replica to the server as described in “Adding a Replica” in the Novell 
eDirectory 8.8 Administration Guide. 


3 Install the NetWare license as described in “Installing and Removing License Certificates” in 
the NW 6.5 SP6: Licensing Services Administration Guide. 


The iManager Licensing plug-in is not installed on OES 2 Linux. If you have configured Role- 
Based Services, you need to make sure the plug-in is installed and added to the RBS collection. 
For more information, see “Upgrading iManager” in the Novell iManager 2.7 Installation 
Guide. 





NOTE: This is only required for the first NetWare server in the tree. After the container exists, 
additional licenses can be installed as required. 





3.10.11 NetWare 6.5 Servers Must Be Running SP3 or Later 


If you are installing OES 2 Linux servers into a tree containing NetWare 6.5 servers, be sure that the 
following server types have been updated to SP3 or later prior to installing OES 2 Linux: 


* SLP Directory Agents: If the SLP Directory Agents on your network are not running NetWare 
6.5 SP3 or later, installing an OES 2 Linux server into the tree can cause the DA servers to 
abend. 


* LDAP Servers: If the LDAP servers referenced in your installation are not running NetWare 
6.5 SP3 or later, the servers might abend during a schema extension operation. 


3.10.12 If You've Ever Had OES 1 Linux Servers with LUM and 
NSS Installed 


Having NSS volumes on OES Linux servers requires certain system-level modifications, most of 
which are automatic. For more information, see Appendix I, “System User and Group Management 
in OES 2 SP1,” on page 263. 
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However, as OES has evolved, some initially defined conventions regarding system Users have 
needed adjustment. Be sure to read the information and follow the instructions in this section if your 
network has ever included an OES 1 Linux server with both LUM and NSS installed. 

* "NetStorage, XTier, and Their System Users" on page 38 

* “An NSS Complication" on page 38 

* "eDirectory Solves the Basic Problem" on page 38 

* "[D Mismatches on OES 1" on page 38 

* "The OES 1 Solution: The nssid.sh Script" on page 39 

+ “OES 2 SP1 Requires a New Approach" on page 39 

* “The OES 2 Solution: Standardizing the UIDs on all OES servers" on page 39 


NetStorage, XTier, and Their System Users 


By default, certain OES services, such as NetStorage, rely on a background Novell service named 
XTier. 


To run on an OES Linux server, XTier requires two system-created users (named novlxsrvd and 
novlxregd) and one system-created group that the users belong to (named novixtier). 


An NSS Complication 


The two system users and their group are created on the local system when XTier is installed. For 
example, they are created when you install NetStorage, and their respective UIDs and GID are used 
to establish ownership of the service's directories and files. 


For NetStorage to run, these XTier users and group must be able to read data on all volume types 
that exist on the OES Linux server. 


As long as the server only has Linux traditional file systems, such as Ext3 and Reiser, NetStorage 
runs without difficulties. 


However, ifthe server has NSS volumes, an additional requirement is introduced. NSS data can only 
be accessed by eDirectory users. Consequently, the local XTier users can't access NSS data, and 
NetStorage can't run properly. 


eDirectory Solves the Basic Problem 


Therefore, when NSS volumes are created on the server, the XTier users are moved to eDirectory 
and enabled for Linux User Management (LUM). See Section 15.2, “Linux User Management: 
Access to Linux for eDirectory Users," on page 153. 


After the move to eDirectory, they can function as both eDirectory and POSIX users, and they no 
longer exist on the local system. 


ID Mismatches on OES 1 


Problems with OES 1 occurred when additional OES NetStorage servers with NSS volumes were 
installed in the same eDirectory container. Because the UIDs and GID were assigned by the Linux 
system, unless the installation process was exactly the same for each OES 1 Linux server, the UIDs 
and GID didn't match server-to-server. 
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When the local XTier UIDs and GID on subsequently installed servers didn’t match the XTier UIDs 
and GID in eDirectory, NetStorage couldn’t access the NSS volumes on the server. 


The OES 1 Solution: The nssid.sh Script 


To solve this problem, the OES 1 installation program looked for XTier ID conflicts, and if the IDs 
on a newly installed server didn't match the IDs in eDirectory, the program generated a script file 
named nssid.sh. The documentation instructed installers to always check for an nssid.sh file on 
a newly installed server, and if the file was found, to run it. The nssid.sh script synchronized all of 
the XTier IDs with those that had already been stored in eDirectory. 


This solution remained viable through the first release of OES 2. 


OES 2 SP1 Requires a New Approach 


Unfortunately, system-level changes in SUSE Linux Enterprise Server 10 SP2 have invalidated the 
nssid.sh script solution for OES 2 SPI. Synchronizing the XTier IDs with an OES 1 installation 
can now cause instability in other non-OES components. Therefore, starting with OES 2 SP1, you 
should standardize all XTier IDs on existing servers before installing a new OES 2 SP1 server with 
XTier-dependent services. 


The OES 2 Solution: Standardizing the UIDs on all OES servers 


If your eDirectory tree has ever contained an OES 1 Linux server with NSS and LUM installed, do 
the following on each server (including OES 2) that has NSS and LUM installed: 
1 Login as root and open a terminal prompt. Then enter the following commands: 
id novlxregd 
id novlxsrvd 


The standardized XTier IDs are UID 81 for novixregd, UID 82 for novixsrvd, and GID 81 


for novixtier. 


2 (Conditional) If you see the following ID information, the XTier IDs are standardized and you 
can start over with Step 1 for the next server: 


uid-81(novlxregd) gid=81(novlxtier) groups-81 (novlxtier) 
uid=82 (novlxsrvd) gid=81(novlxtier) groups-81 (novlxtier) , 8 (www) 


3 (Conditional) If you see different IDs than those listed above, such as 101, 102, 103, etc., 
record the numbers for both XTier users and the novlxtier group, then continue with Step 4. 


You need these numbers to standardize the IDs on the server. 
4 Download the following script file: 


* fix xtier_ids.sh (http://www.novell.com/documentation/oes2/scripts/ 
fix_xtier_ids.sh) 


5 Customize the template file by replacing the variables marked with angle brackets (<>) as 
follows: 


* «server name»: The name of the server object in eDirectory. 
This variable is listed on line 38 in the file. Replace it with the server name. 


For example, if the server name is myserver, replace «server name? with myserver so 
that the line in the settings section of the script reads 
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Server-myserver 
* «context»: This is the context of the XTier user and group objects. 


Replace this variable with the fully distinguished name of the context where the objects 
reside. 


For example, if the objects are an Organizational Unit object named servers, replace 
ou-servers,o-company with the fully distinguished name. 


* «admin fdn>: The full context of an eDirectory admin user, such as the Tree Admin, who 
has rights to modify the XTier user and group objects. 


Replace this variable with the admin name and context, specified with comma-delimited 
syntax. 


For example, if the tree admin is in an Organization container named company, the full 
context is cn=admin,o=company and the line in the settings section of the script reads 


admin fdn-"cn-admin,o-company" 


+ «novlxregd uid»: This is the UID that the system assigned to the local novi xregd user. 
It might or might not be the same on each server, depending on whether the nssid.sh 
script ran successfully. 


Replace this variable with the UID reported for the novlxregd user on this server as listed 
in Step 1 on page 39. 


For example, if the UID for the novlxregd user is 101, change the line to read 
novixregd uid-101 


* «novlxsrvd uid»: This is the UID that the system assigned to the local novlxsrvd user. It 
might or might not be the same on each server, depending on whether the nssid.sh script 
ran successfully. 


Replace this variable with the UID reported for the novlxsrvd user on this server as listed 
when you ran the commands in Step 1 on page 39. 


For example, if the UID for novlxsrvd uid is 102, change the line to read 
novixsrvd uid-102 


* <novixtier_gid>: This is the GID that the system assigned to the local novlxtier group. It 
might or might not be the same on each server, depending on whether the nssid.sh script 
ran successfully. 


Replace this variable with the GID reported for the novlxtier group on this server as listed 
when you ran the commands in Step 1 on page 39. 


For example, if the GID for novlxtier gid is 101, change the line to read 
novlxtier gid-101 


6 Make the script executable and then run it on the server. 





IMPORTANT: Changes to the XTier files are not reported on the terminal. 


Error messages are reported, but you can safely ignore them. The script scans the entire file 
system, and some files are locked because the system is running. 





7 Repeat from Step 1 for each of the other servers in the same context. 
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3.10.13 Novell Distributed Print Services Cannot Migrate to 
Linux 


NDPS*? clients are not supported on Linux. You must therefore migrate any NDPS clients to iPrint 
before you migrate your print services to OES 2 Linux. For more information, see “Migrating NDPS 
Printers to iPrint” in the NW 6.5 SP6: iPrint Administration Guide. 


3.10.14 NSS Caveats 


* "About New Media Support and Clusters" on page 41 
* "Removable Media Cannot Be Mounted on OES 2 Linux" on page 41 


About New Media Support and Clusters 


The new media support for hard links on OES 2 NSS volumes was not available for OES 1 SP2 
Linux and earlier, but it was available for NetWare 6.5 SP4 and OES 1 NetWare SP1 and later. 


If you've already upgraded the media format of the volume, you cannot fail over to a node that is 
running OES 1 SP2 Linux until you have upgraded the node to OES 2 Linux. 


Removable Media Cannot Be Mounted on OES 2 Linux 


CD and DVD media and image files cannot be mounted as NSS volumes on Linux; instead, they are 
mounted as Linux POSIX file systems. 


For more details about NSS compatibility, see “Cross-Platform Issues for NSS Volumes" in the NW 
6.5 SP6: NSS File System Administration Guide. 


3.10.15 Unsupported Service Combinations 
Do not install any of the following service combinations on the same server. Although not all of the 


combinations shown in Table 3-3 cause pattern conflict warnings, Novell does not support any of 
them. 


Table 3-3 Unsupported Service Combinations 


Service Unsupported on the Same Server 
Novell AFP * File Server (Samba) 
* Netatalk 


* Novell Domain Services for Windows 
* Novell Samba 


There is an exception if NCP server is 
installed on the same server as Novell AFP. 


To support cross-protocol file locking between 
Novell AFP and NCP, Samba must be 
installed on the server, but it cannot be used 
for providing file services to CIFS or SMB 
clients. 


* Xen Virtual Machine Host Server 
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Service 


Novell Archive and Version Services 


Novell Backup / Storage Management Services 


Novell CIFS 


Novell Cluster Services (NCS) 


Novell DHCP 
Novell DNS 


Novell Domain Services for Windows 


Novell eDirectory 


Novell FTP 


Novell iFolder 


Novell iManager 
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* 


* 


* 


* 


* 


Unsupported on the Same Server 


Novell Domain Services for Windows (DSfW) 


Xen Virtual Machine Host Server 


No restrictions 


File Server (Samba) 

Novell Domain Services for Windows 
Novell Samba 

Xen Virtual Machine Host Server 
High Availability 

Novell Domain Services for Windows 


DSfW can actually be installed and run on the 
same server as NCS, but DSfW cannot run as 
a clustered service. 


Xen Virtual Machine Host Server 


DHCP and DNS Server 


Xen Virtual Machine Host Server 


File Server (Samba) 

Novell AFP 

Novell Archive and Version Services 

Novell CIFS 

Novell Cluster Services (NCS) 

NCS can actually be installed and run on the 


server, but DSfW cannot run as a clustered 
service. 


Novell FTP 

Novell iFolder 

Novell NetStorage 

Novell Pre-Migration Server 
Novell QuickFinder 

Novell Samba 


Xen Virtual Machine Host Server 


Directory Server (LDAP) 


Xen Virtual Machine Host Server 


Novell Domain Services for Windows 


Xen Virtual Machine Host Server 


Novell Domain Services for Windows 


Xen Virtual Machine Host Server 


Xen Virtual Machine Host Server 


Service 


Novell iPrint 


Novell Linux User Management (LUM) 
Novell NCP Server / Dynamic Storage Technology 


Novell NetStorage 


Novell Pre-Migration Server 


Novell QuickFinder 


Novell Remote Manager (NRM) 


Novell Samba 


Novell Storage Services (NSS) 


Unsupported on the Same Server 


* 


* 


Print Server (CUPS) 

CUPS components are actually installed, but 
CUPS printing is disabled. For more 
information, see Section 6.7.6, "iPrint 
Disables CUPS Printing on the OES 2 
Linux Server," on page 65. 


Xen Virtual Machine Host Server 


No restrictions 


* 


* 


* 


* 


Xen Virtual Machine Host Server 


Novell Domain Services for Windows 


Xen Virtual Machine Host Server 


Novell Domain Services for Windows 


Xen Virtual Machine Host Server 


Novell Domain Services for Windows 


Xen Virtual Machine Host Server 
Xen Virtual Machine Host Server 


File Server (Samba) 
Novell CIFS 
Novell Domain Services for Windows 


Xen Virtual Machine Host Server 


Xen Virtual Machine Host Server 
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Service Unsupported on the Same Server 


Xen Virtual Machine Host Server * File Server (Samba) 
* Novell AFP 
* Novell Archive and Version Services 
* Novell CIFS 
* Novell DHCP 
* Novell DNS 
* Novell Domain Services for Windows 
* Novell eDirectory 
* Novell FTP 
* Novell iFolder 
* Novell iManager 
* Novell iPrint 


* Novell NCP Server / Dynamic Storage 
Technology 


* Novell NetStorage 

* Novell Pre-Migration Server 

* Novell QuickFinder 

* Novell Remote Manager (NRM) 
* Novell Samba 

* Novell Storage Services 

* Print Server (CUPS) 


3.11 Consider Coexistence and Migration Issues 


You probably have a network that is already providing services to network users. In many cases, the 
services you are currently running will influence your approach to implementing OES 2. In some 
cases, there are specific paths to follow so that the OES 2 integration process is as smooth as 
possible. 


Novell has invested considerable effort in identifying service coexistence and migration issues you 
might face. We understand, however, that we can't anticipate every combination of services that you 
might have. Therefore, we intend to continue developing coexistence and migration information 
after each OES product release, and we plan to update the Web-based documentation regularly with 
the newly developed information. 


For information about coexistence of OES 2 servers with existing NetWare and Linux networks, see 
Chapter 8, “Migrating and Consolidating Existing Servers and Data,” on page 73. 


3.12 Understand Your Installation Options 


Before installing OES, you should be aware of the information in the following sections: 


* Section 3.12.1, “OES 2 Linux Installation Overview,” on page 45 
* Section 3.12.2, *OES 2 NetWare Installation Overview," on page 46 
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* 


* 


* 


* 


Section 3.12.3, “About Your Installation Options," 
Section 3.12.4, *Use Predefined Server Types (Patterns) When Possible," on page 47 
Section 3.12.5, “If You Want to Install in a Lab First,” on page 48 
Section 3.12.6, “If You Want to Install NSS on a Single-Drive Linux Server,” on page 48 


on page 46 


3.12.1 OES 2 Linux Installation Overview 


The software and network preparation processes required to install OES 2 Linux are outlined in 


Figure 3-1. 





NOTE: Chapter 4, “Getting and Preparing OES 2 Software," on page 49 contains instructions for 
obtaining the ISO image files and the network install script referred to in the following illustration. 





Figure 3-1 OES 2 Linux Install Preparation 
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media from the 
downloaded ISO 
files as instructed. 
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Deployment Manager 
> eDirectory 
Preparation option. 


(Requires access to 
the [root] partition.) 
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For detailed instructions, see “Setting Up an Installation Source" in the OES 2 SP2: Installation 
Guide. 


3.12.2 OES 2 NetWare Installation Overview 


The software and network preparation processes required to install OES 2 NetWare are outlined in 
Figure 3-2. Specific instructions for the steps shown are referenced in the sections that follow. 





NOTE: Chapter 4, “Getting and Preparing OES 2 Software," on page 49 contains instructions for 
obtaining the ISO image files referred to in the following illustration. 





Figure 3-2 OES 2 Netware Install Preparation 
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For detailed instructions, see *NW65 SP8: Installation Guide” in the NW65 SP8: Installation Guide. 


3.12.3 About Your Installation Options 


As illustrated in the two previous sections, OES 2 Linux lets you install from physical media or from 
files on the network, but NetWare requires physical media. 


* “OES 2 Linux Options" on page 47 
* "OES 2 NetWare Options" on page 47 


* “Virtual Machine Installation Options" on page 47 
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OES 2 Linux Options 


OES 2 Linux includes numerous installation options as documented in the OES 2 SP2: Installation 
Guide. 


* CD/DVD Install: You can install SLES 10 SPI by using CDs or a DVD and then install OES 2 
Linux from a CD, all of which can be either obtained from a Novell Authorized Reseller or 
created from downloaded ISO image files. 


See "Preparing Physical Media for a New Server Installation or an Upgrade ” in the OES 2 
SP2: Installation Guide. 


* Network Install: You can install from the network by using the NFS, FTP, or HTTP protocol. 
Installing from the network saves you from swapping CDs on the server during the installation. 
See "Preparing a Network Installation Source" in the OES 2 SP2: Installation Guide. 

* Automated Install: You can install from the network by using an AutoYaST file. 


This lets you install without providing input during the installation process. It is especially 
useful for installing multiple servers with similar configurations. 


See "Using AutoYaST to Install and Configure Multiple OES Servers” in the OES 2 SP2: 
Installation Guide. 


OES 2 NetWare Options 
OES 2 NetWare installation options are documented in the NW65 SP6: Installation Guide. 


* CD/DVD Install: You can install by using CDs or a DVD obtained from a Novell Authorized 
Reseller, or you can create CDs or a DVD from downloaded ISO image files. 


See “Accessing the Installation Files” in the NW65 SP8: Installation Guide. 


Virtual Machine Installation Options 
Virtual machine installations offer additional options. For more information, see 


+ "Installing, Upgrading, or Updating OES on a Xen-based VM"in the OES 2 SP2: Installation 
Guide 


+ “Installing and Managing NetWare on a Xen-based VM” in the OES 2 SP2: Installation Guide. 


3.12.4 Use Predefined Server Types (Patterns) When Possible 


Both OES 2 Linux and OES 2 NetWare include predefined server installation options that install 
only the components required to provide a specific set of network services. In the OES 2, these 
server types are called patterns. 


For example, if you want to install an OES 2 server that provides enterprise level print services, you 
should select the Novell iPrint Server pattern during the installation. 


You should always choose a predefined server type if one fits the intended purpose of your server. If 
not, you can choose to install a customized OES 2 server with only the service components you 
need. 
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More information about server patterns is available in the installation guides: 


+ OES 2 Linux: “OES Services Pattern Descriptions” in the OES 2 SP2: Installation Guide 
+ OES 2 NetWare: “Choosing a Server Pattern” in the NW65 SP8: Installation Guide 


3.12.5 If You Want to Install in a Lab First 


Many organizations prefer to install products on smaller servers for testing in a lab prior to full 
deployment. The OES 2 SP2: Lab Guide for Linux and Virtualized NetWare walks you through 
installing and exploring all the basic OES 2 services. 


3.12.6 If You Want to Install NSS on a Single-Drive Linux Server 


Many are interested in Novell Storage Services (NSS) running on Linux. If you plan to experiment 
with NSS on a single-drive server, be sure to follow the instructions in “Installing with EVMS as the 
Volume Manager of the System Device” in the OES 2 SP2: Installation Guide. 


3.13 eGuide, IFolder 2, and Virtual Office Are Still 
Available on Netware 


Contrary to the direction announced for the initial release of OES 2, Novell has decided that eGuide, 
iFolder 2, and Virtual Office will not be removed from NetWare 6.5 (OES 2 NetWare). There are no 
plans to make them available on OES 2 Linux. 


The designated replacement services are as follows: 


+ eGuide: Replaced in the Identity Manager 3.6 User Application by the functionality in the Self- 
Service tab. A separate purchase is required. See “Using the Identity Self-Service Tab” (http:// 
www.novell.com/documentation/idmrbpm36/ugpro/data/ugpropartidentity. html) in the Identity 
Manager 3.6 User Application Documentation on the Web (http://www.novell.com/ 
documentation/idmrbpm36/ugpro/data/bookinfo.html). 

* Folder 2: Replaced by iFolder 3.7, which is included in OES 2 SP1 Linux. For more 
information, see Section 17.10, *Novell iFolder 3.7 Implementation and Maintenance," on 
page 215. 

* Virtual Office: Replaced by Novell Teaming + Conferencing. A separate purchase is required. 
For more information, see the Novell Teaming + Conferencing Web Site (http:// 
www.novell.com/products/teaming/index.html). 


Documentation for these components on NetWare is available on the OES 1 Documentation Web 
site (http://www.novell.com/documentation/oes). 
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Getting and Preparing OES 2 
Software 


This section contains instructions for getting and preparing Open Enterprise Server 2 software and 
discusses the following topics: 

* Section 4.1, “Do You Have Upgrade Protection?,” on page 49 

* Section 4.2, “Do You Want 32-Bit or 64-Bit OES Linux?,” on page 49 

* Section 4.3, “Do You Want to Purchase OES 2 or Evaluate It?," on page 50 

* Section 4.4, "Evaluating OES 2 Software," on page 50 

¢ Section 4.5, "Licensing," on page 54 


If you have not already done so, we recommend that you review the information in Section 3.12, 
"Understand Your Installation Options," on page 44. 


4.1 Do You Have Upgrade Protection? 


If you have Novell® Upgrade Protection, you can upgrade to OES 2 and the associated support 
packs, free of charge until your upgrade protection expires. After your protection expires, the OES 2 
upgrade link disappears from your account page. 


For more information and to start the upgrade process, do the following: 
1 Using your Novell account information, log in to the Novell Web Site (http://www.novell.com/ 
nps). 


2 Click Customer Center and log in, using your Novell account username and password to access 
the Novell Customer Center home page. 


3 Follow the instructions on the page to obtain the upgrade to Open Enterprise Server 2. 


4.2 Do You Want 32-Bit or 64-Bit OES Linux? 


Compatibility is the first thing to consider as you start planning which software to download and 
install. 


OES NetWare® (NetWare 6.5) is a 32-bit operating system that you can install on both 32-bit and 
64-bit server hardware. 


OES Linux, on the other hand, is a set of services or an “add-on product” that runs on SUSE® Linux 
Enterprise Server (SLES 10) and is available in both 32-bit and 64-bit versions. These two versions 
are required for compatibility with SLES 10 and the server hardware that it runs on. Having two 
versions of OES Linux introduces a little more complexity into your planning, as illustrated in Table 
4-1. 
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Table 4-1 OES 2, SLES 10, and Server Hardware Compatibility Matrix 


OES 2 SP1 


; SLES 10 SP2 Server Hardware Notes 
Version 


32-bit (i386) 32-bit (i386) 32-bit The 32-bit version of OES 2 SP1 requires the 32- 

bit version of SLES 10 SP2. 
64-bit 

Attempting to install the 32-bit version of OES as 
an add-on product to the 64-bit version of SLES 
10 generates numerous dependency errors 
because the 32-bit OES 2 install is looking for 32- 
bit SLES 10 packages. 


32-bit software (OES and SLES) can be installed 
on either 32-bit or 64-bit hardware. 


64-bit (x86 64) 64-bit (x86 64)  64-bit The 64-bit version of OES 2 SP1 requires the 64- 
bit version of SLES 10 SP2, and they can only be 
installed on 64-bit hardware. 


4.3 Do You Want to Purchase OES 2 or Evaluate 
It? 


If you want to evaluate OES prior to purchasing it, skip to the next section, Evaluating OES 2 
Software. 


If you have decided to purchase OES 2, visit the Novell How to Buy OES 2 Web page (http:// 
www.novell.com/products/openenterpriseserver/howtobuy.html). 


When you purchase OES 2, you receive two activation codes for OES 2 Linux (one for OES 2 
services and one for SUSE Linux Enterprise Server 10). Both codes are required for registering an 
OES 2 Linux system in the Novell Customer Center. After it is registered, your server can receive 
online updates, including the latest support pack. 





NOTE: Purchasing OES 2 also lets you obtain OES 2 NetWare support packs at no charge as they 
become available on the Novell Support Web site (http://support.novell.com/filefinder/) 





As part of the purchase process, it is important that you understand the OES 2 licensing model. For a 
brief description, see Section 4.5, "Licensing," on page 54. A more thorough explanation of Novell 
Licensing Services (NLS) is contained in the NW 6.5 SP8: Licensing Services Administration Guide. 


After completing your purchase, the installation process goes more smoothly if you understand your 
installation options for each OES 2 platform. If you haven't already done so, be sure to review the 
information in Section 3.12, “Understand Your Installation Options," on page 44 and then skip to 
Chapter 5, "Installing OES 2," on page 57. 


4.4 Evaluating OES 2 Software 


This section walks you through the OES 2 software evaluation process and discusses the following 
topics: 


* Section 4.4.1, “Understanding OES 2 Software Evaluation Basics,” on page 51 
* Section 4.4.2, “Downloading OES 2 SP1 Software from the Novell Web Site," on page 51 
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Section 4.4.3, "Preparing the Installation Media,” on page 52 
Section 4.4.4, "Installing OES 2 for Evaluation Purposes," on page 53 
Section 4.4.5, “Evaluating OES 2," on page 53 


Section 4.4.6, "Installing Purchased Activation Codes after the Evaluation Period Expires," on 
page 54 


4.4.1 Understanding OES 2 Software Evaluation Basics 


You can evaluate the full OES 2 product on both product platforms (Linux and NetWare). The 
evaluation software is the complete, fully functional OES 2 product. 


As you install each server, you are required to accept an end user license agreement (EULA). Your 
rights to evaluate and use the OES 2 product are limited to the rights set forth in the EULA, which 
are, briefly, the following: 


* The evaluation period for OES 2 Linux servers is 60 days. To receive software updates during 


this time, you must have or create an account with the Customer Center, receive evaluation 
codes for OES 2 and SLES 10 while downloading the software, and use these codes to register 
your server. No software updates can be downloaded after the 60-day evaluation period expires 
until you purchase the product. 


The evaluation period for OES 2 NetWare servers is 90 days, after which Novell expects you to 
either purchase OES 2 or uninstall OES 2 NetWare. 


4.4.2 Downloading OES 2 SP1 Software from the Novell Web 
Site 


If you already have OES 2 SP1 ISO image files, skip to Section 4.4.3, "Preparing the Installation 
Media," on page 52. 


If you have OES 2 SPI product media (CDs and DVDs), skip to Section 4.4.4, “Installing OES 2 for 
Evaluation Purposes," on page 53. 


To download ISO image files from the Web: 


1 


If you don't already have a Novell account, register for one on the Web (https://secure- 
www.novell.com/selfreg/jsp/createAccount.jsp?). 


2 Access the Novell Downloads Web page (http://download.novell.com). 


Do a keyword search for Open Enterprise Server 2 SPI, then click the Open Enterprise Server 
2 SPI e-Media Kit link. 


Click the proceed to download button (upper right corner of the first table). 


If you are prompted to log in, type your Novell Account > username and password, then click 
login. 


Accept the Export Agreement (required for first downloads only) and answer the survey 
questions about your download (optional). 


Print the download page. You need the listed MDS verification numbers to verify your 
downloads. 


Scroll down to the Download Instructions section and click the Download Instructions link. 


9 Print the Download Instructions page for future reference. 
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10 


11 


12 


13 


14 
15 


16 


17 


18 


Use the information on the Download Instructions page to decide which files you need to 
download for the platforms you plan to evaluate, then mark them on the MD5 verification list 
on the page you printed in Step 7. 


On the download page, start downloading the files you need by clicking the download button 
for each file. 


If you have purchased OES 2 previously and received purchased OES 2 and SLES 10 
activation codes, skip to Step 15. 


Otherwise, in the Evaluating Open Enterprise Server 2 section, click the Get Activation Codes 
link in the Novell Open Enterprise Server 2—Linux paragraph. 


60-day evaluation codes are sent in separate e-mail messages to the e-mail address associated 
with your Novell account. 


Access your e-mail account and print the messages or write down the activation codes. 


Both the OES 2 and the SLES codes are required for product registration and downloading 
software updates. 


Click Back to return to the download page. 


In the download table at the top of the page, click the /nstall Instructions > View link at the end 
of the list of files to download. 


Although you might have printed this file earlier, the online version is required for the steps 
that follow. 


Scroll past the download decision tables; while you wait for the downloads, read through the 
brief installation instructions, clicking the links for more information. 


Verify the integrity of each downloaded file by running an MD5-based checksum utility on it 
and comparing the values against the list you printed in Step 15. 


For example, on a Linux system you can enter the following command: 
md5sum filename 
where filename is the name of the . iso file you are verifying. 


For a Windows system, you need to obtain a Windows-compatible MD5-based checksum 
utility from the Web and follow its usage instructions. 


(Optional) If you plan to install OES 2 Linux from files on your network, see the instructions in 
"Preparing a Network Installation Source" in the OES 2 SP2: Installation Guide. 


4.4.3 Preparing the Installation Media 





IMPORTANT: If you have downloaded . iso image files from the Web, it is critical that you verify 
the integrity of each file as explained in Step 17 on page 52. Failure to verify file integrity can result 
in failed installations, especially in errors that report missing files. 





Instructions for preparing installation media are located in 


* 


* 


“Setting Up an Installation Source" in the OES 2 SP2: Installation Guide. 
“Preparing the NetWare Installation Software"in the NW65 SP8: Installation Guide. 
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4.4.4 Installing OES 2 for Evaluation Purposes 


The following sections explain how to activate your OES 2 servers for evaluation purposes. Detailed 
instructions are found in the platform-specific installation guides. 


* “OES 2 Linux” on page 53 
* “OES 2 NetWare” on page 53 


OES 2 Linux 


If you followed the instructions in Section 4.4.2, “Downloading OES 2 SP1 Software from the 
Novell Web Site,” on page 51, you now have two activation codes (for the purchased product and 
for a 60-day evaluation). As you install OES 2 Linux, you should register with the Novell Customer 
Center and use these activation codes to enable your server for online updates. 


IMPORTANT: Always download the current patches during an installation. 





Instructions for using the activation codes during an installation are found in “To register the server 
during the installation:” in the OES 2 SP2: Installation Guide. 


Use the same activation codes for each OES 2 Linux server you install during the evaluation period. 


OES 2 NetWare 














All OES 2 NetWare installation media contains a \LICENSE folder with a non-expiring MLA license 
file in it. You should select this license when you install the first OES 2 NetWare evaluation server in 
a new tree. Subsequent NetWare installations use the same license. 


For an explanation of why an MLA license is now included and to understand the benefits and 
limitations associated with this change, see “NetWare 6.5 SP8 Includes MLA License Files” in the 
NW 6.5 SP8: Licensing Services Administration Guide. 


Instructions for installing NetWare licenses are contained in “Licensing the NetWare Server” in the 
NW65 SP8: Installation Guide. 


4.4.5 Evaluating OES 2 


During the evaluation period, we recommend that you fully explore the many services available in 
OES 2. 


To help you get started with the process, we have prepared a lab guide for OES 2 that explores both 
OES 2 Linux and virtualized OES 2 NetWare on a second OES 2 Linux server. The sections in this 
guide introduce eDirectory™, walk you through server installations, and provide brief exercises you 
can complete to get started using OES 2 Services. After completing the exercises in the guide, you 

can use the lab setup to further explore OES 2 and learn about its many powerful services. 


For more information, see the OES 2 SP2: Lab Guide for Linux and Virtualized NetWare. 


After working through the lab guide, we recommend that you review all of the information in this 
guide to gain a comprehensive overview of OES 2 and the planning and implementation processes 
you will follow to fully leverage its network services. 
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4.4.6 Installing Purchased Activation Codes after the 
Evaluation Period Expires 

After purchasing Open Enterprise Server, use the instructions in “Registering the Server in the 
Novell Customer Center (Command Line)" in the OES 2 SP2: Installation Guide to enter the 
purchased activation codes that you received with your purchase. After logging in as root, complete 


the step where you enter the activation codes, replacing the evaluation codes with the purchased 
codes. 


4.5 Licensing 


This section explains the following: 


* Section 4.5.1, “The OES 2 Licensing Model," on page 54 

* Section 4.5.2, “SLES Licensing Entitlements in OES 2,” on page 54 
* Section 4.5.3, “Licensing Services on OES 2 NetWare,” on page 54 
* Section 4.5.4, “OES 2 Linux Doesn't Support NLS,” on page 55 


* Section 4.5.5, “Configuring and Administering Licensing Services,” on page 55 


4.5.1 The OES 2 Licensing Model 


The only OES 2 licensing restriction is the number of user connections allowed to use OES 2 
services on your network. You are authorized to install as many OES 2 servers (both Linux and 
NetWare) as you need to provide OES 2 services to those users. 


For example, if your OES 2 license is for 100 user connections, you can install as many OES 2 
NetWare and/or OES 2 Linux servers as desired. Up to 100 users can then connect to and use the 
services provided by those OES 2 servers. When you install OES 2 on either platform, you must 
accept an end user license agreement (EULA). Your rights to use the OES 2 product are limited to 
the rights set forth in the EULA. Violators of the Novell license agreements and intellectual property 
are prosecuted to the fullest extent of the law. 


To report piracy and infringement violations, please call 1-800-PIRATES (800-747-2837) or send e- 
mail to pirates@novell.com. 


For more information on OES 2 licensing, see the OES 2 Licensing page on the Novell Web site 
(http://www.novell.com/licensing/oes_licensing.html). 


4.5.2 SLES Licensing Entitlements in OES 2 


SUSE Linux Enterprise Server (SLES) entitlements in OES 2 changed on September 1, 2009. For 
more information, refer to the EULA (http://www.novell.com/licensing/eula/oes/ 
oes 2 english.pdf). 


4.5.3 Licensing Services on OES 2 NetWare 
When you install or upgrade NetWare, the server installation software automatically installs the 


Novell Licensing Services (NLS) software. During the installation of the first NetWare server in a 
tree, you are prompted for a license/key file pair (*.n1f and *.n£k). 
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Starting with OES 2, a non-expiring MLA NetWare license file is included on the installation media 
in the \LICENSE folder. Installing this license effectively removes the NLS-based enforcement of 
user connection limitations as it existed in earlier versions of NetWare. However, user connection 
limitations are still in force as defined in each license agreement (referred to as a paper license) 
issued by Novell when you purchase OES 2. 














For an explanation of why an MLA license is now included and to understand the benefits and 
limitations associated with this change, see “NetWare 6.5 SP8 Includes MLA License Files” in the 
NW 6.5 SP6: Licensing Services Administration Guide. 


After installing OES 2, you can use Novell iManager to install and manage license certificates in 
your eDirectory tree and to monitor NetWare usage. You can also monitor usage of Novell Licensing 
Services-enabled products. 


4.5.4 OES 2 Linux Doesn't Support NLS 


Novell Licensing Services (NLS) are not available on OES 2 Linux, nor does an OES 2 Linux 
installation require a license/key file pair (*.n1£ and *.nfk). 


4.5.5 Configuring and Administering Licensing Services 


See the related topics in “Licensing” in the OES online documentation. 
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Installing OES 2 





IMPORTANT: Before you install Open Enterprise Server 2, be sure to review the information in 
Chapter 3, “Planning Your OES 2 Implementation,” on page 23, especially Section 3.10, “Caveats 
to Consider Before You Install,” on page 33. 





This section briefly covers the following: 


¢ Section 5.1, “Installing OES 2 Linux,” on page 57 
* Section 5.2, “Installing OES 2 NetWare,” on page 58 
* Section 5.3, “Installing OES 2 Servers in a Xen VM,” on page 58 


5.1 Installing OES 2 Linux 


The OES 2 Linux installation leverages the SUSE® Linux YaST graphical user interface. You can 
install OES 2 Linux services on an existing SUSE Linux Enterprise Server 10 server, or you can 
install both OES 2 and SLES 10 at the same time, making the installation of SLES 10 and OES 2 
services a seamless process. 


To ensure a successful installation: 
1. Read and follow any instructions in the OES 2 Readme (http://www.novell.com/ 
documentation/oes2/oes_readme/data/oes_readme.html#bsen7me). 


2. Carefully follow the instructions in the OES 2 SP2: Installation Guide, especially those found 
in 


* “Preparing to Install OES 2 SP2” 
* “Installing OES 2 SP2” 


3. Make sure you always download the latest patches as part of the Customer Center 
configuration during the install. This ensures the most stable configuration and installation 
process and prevents some issues that are documented in the product Readme. 


4. After updating the server, red text appears under the CA Management section, indicating that 
the CA must be configured before proceeding. 


This happens because the root password is no longer in memory after the server reboots. 


Click CA Management, type and confirm the root password in the indicated fields, then click 
Next. The installation proceeds. 


5. During the installation, you have the option to disable each service configuration. However, we 
recommend that you configure all services at install time simply because the process is more 
streamlined. 


For more information on configuring services later, see “Installing/Configuring OES 2 SP2 on 
an Existing Server” in the OES 2 SP2: Installation Guide. 


5.1.1 What's Next 


After installing OES 2 and before starting to use your new OES 2 Linux server, be sure to review the 
information in Chapter 6, “Caveats for Implementing OES 2 Services,” on page 59. 
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The various service sections in this guide contain information about completing your OES 2 services 
implementation. See the sections for the services you have installed, beginning with Chapter 11, 
“Managing OES 2,” on page 81. 


5.2 Installing OES 2 NetWare 


Installing OES 2 NetWare” (NetWare 6.5) directly on a physical server involves the NetWare 
graphical user interface. 


To ensure a successful installation: 
1. Read and follow any instructions in the OES 2 Readme (http://www.novell.com/ 
documentation/oes2/oes_readme/data/oes_readme.html#bsfogt4). 


2. Carefully follow the instructions in the NW65 SP8: Installation Guide, especially those found 
in 


* “Preparing to Install NetWare 6.5 SP8” 
¢ “Installing NetWare 6.5 SP8 (Physical)” 


5.2.1 What's Next 


After installing OES 2 and before starting to use your new OES 2 NetWare server, be sure to follow 
the instructions in Chapter 6, “Caveats for Implementing OES 2 Services,” on page 59. 


The various service sections in this guide contain information about completing your OES 2 services 
implementation. See the sections for the services you have installed, beginning with Chapter 11, 
“Managing OES 2,” on page 81. 


5.3 Installing OES 2 Servers in a Xen VM 


Installing OES 2 servers on a Xen virtual machine involves installing an OES 2 SP1 Linux or 
SUSE® Linux Enterprise Server (SLES) 10 SP2 VM host server, creating a VM, and then installing 
an OES 2 server (NetWare or Linux) in the VM. 


To get started with Xen virtualization in OES 2, see the following: 


* “Introduction to Xen Virtualization” (http://www.novell.com/documentation/sles10/ 
book_virtualization_xen/data/sec_xen_basics.html) in the Virtualization with Xen (http:// 
www.novell.com/documentation/sles10/book virtualization xen/data/ 
book virtualization xen.html) guide. 


* “Installing, Upgrading, or Updating OES on a Xen-based VM” in the OES 2 SP2: Installation 
Guide. 


+ “Installing and Managing NetWare on a Xen-based VM" in the OES 2 SP2: Installation Guide. 
* “Installing OES as a Xen VM Host Server" in the OES 2 SP2: Installation Guide. 
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Caveats for Implementing OES 2 
Services 


This section presents a few pointers for avoiding common Open Enterprise Server 2 implementation 
problems. 


The list that follows is not comprehensive. Rather, it simply outlines some of the more common 
problems reported by network administrators. To ensure successful service implementations, you 
should always follow the instructions in the documentation for the services you are implementing. 

* Section 6.1, “Avoiding POSIX and eDirectory Duplications,” on page 59 

* Section 6.2, “ConsoleOne Can Cause JClient Errors,” on page 61 

* Section 6.3, "CUPS on OES 2 Linux," on page 62 

¢ Section 6.4, “eDirectory,” on page 62 

* Section 6.5, “iManager 2.7,” on page 63 

* Section 6.6, “iFolder 3.8," on page 64 

¢ Section 6.7, “iPrint,” on page 64 

* Section 6.8, “NCP Server (OES 2 Linux),” on page 65 

* Section 6.9, “NSS (OES 2 Linux),” on page 66 

* Section 6.10, “OpenLDAP on OES 2 Linux,” on page 66 

¢ Section 6.11, “Samba,” on page 66 

¢ Section 6.12, “Virtualization Issues,” on page 66 


* Section 6.13, “Web Services," on page 67 


6.1 Avoiding POSIX and eDirectory Duplications 


OES 2 Linux servers can be accessed by 


* Local (POSIX) users that are created on the server itself. 


* eDirectory users that are given local access through Linux User Manager (LUM). 
However, there are some issues you need to consider: 


* Section 6.1.1, “The Problem,” on page 59 
* Section 6.1.2, “Three Examples," on page 60 
* Section 6.1.3, “Avoiding Duplication," on page 61 


6.1.1 The Problem 


There is no cross-checking between POSIX and eDirectory™ to prevent the creation of users or 
groups with duplicate names. 
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When duplicate names occur, the resulting problems are very difficult to troubleshoot because 
everything on both the eDirectory side and the POSIX side appears to be configured correctly. The 
most common problem is that LUM-enabled users can’t access data and services as expected but 
other errors could surface as well. 


Unless you are aware of the users and groups in both systems, especially those that are system- 
created, you might easily create an invalid configuration on an OES 2 Linux server. 


6.1.2 Three Examples 


The following examples illustrate the issue. 


* “The shadow Group" on page 60 
* “The users Group” on page 60 


* "Other Non-System Groups" on page 60 


The shadow Group 


There is a default system-created group named shadow that is used by certain Web-related services, 
including the OES 2 QuickFinder™ server, but it has no relationship with Dynamic Storage 
Technology (DST) and shadow volumes. 


Because shadow is a local POSIX group, there is nothing to prevent you from creating a LUM- 
enabled second group in eDirectory that is also named shadow. In fact, this could be a logical name 
choice for many administrators in conjunction with setting up shadow volume access for Samba/ 
CIFS users. 


However, using this group name results in LUM-enabled users being denied access by POSIX, 
which looks first to the local shadow group when determining access rights and only checks 
eDirectory for a group named shadow if no local group is found. 


The users Group 


There is another default system-created group named users that is not used by OES 2 services but is 
nevertheless created on all SLES 10 (and therefore, OES 2 Linux) servers. 


Creating an eDirectory group named users would seem logical to many administrators. And as with 
the shadow group, nothing prevents you from using this name. 


Unfortunately, having a LUM-enabled eDirectory group named users is not a viable configuration 
for services requiring POSIX access. The local users group is always checked first, and the LUM- 
enabled users group in eDirectory won't be seen by POSIX. 





NOTE: Do not confuse eDirectory Group objects with Organizational Unit (OU) container objects. 


Creating an OU container in eDirectory named users is a valid option and does not create conflicts 
with POSIX. 


Other Non-System Groups 


Conflicts between group and user names also occur when administrators create local and eDirectory 
groups with the same name. 
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For example, one administrator creates a group named myusers on the local system and another 
creates a LUM-enabled group in eDirectory with the same name. Again, the LUM-enabled users 
who are members of the eDirectory group won’t have access through POSIX. 


This is why we recommend that, as a general rule, administrators should not create local users or 
groups on OES 2 Linux servers. You should only make exceptions when you have determined that 
using LUM-enabled users and groups is not a viable option and that objects with the same names as 
the POSIX users and groups will not be created in eDirectory in the future. 


6.1.3 Avoiding Duplication 


Having duplicate users and groups is easily avoided by following these guidelines: 


* "Use YaST to List All System-Created Users and Groups" on page 61 
* "Create Only eDirectory Users and Groups" on page 61 


Use YaST to List All System-Created Users and Groups 


We recommend that you use the YaST Group Management/User Management module to check for 
names you might duplicate by mistake. 

1. Open the YaST Control Center. 

2. Click either Group Management or User Management. 

3. Click Set Filter > Customize Filter. 

4. Select both options (Local and System), then click OK. 


All users or groups as displayed, including those that exist only in eDirectory and are LUM- 
enabled. 


5. To avoid duplication, keep this list in mind as you create eDirectory users and groups. 





NOTE: The list of users and groups in Appendix I, “System User and Group Management in OES 2 
SP1,” on page 263 is not exhaustive. For example, the users group is not listed. 





Create Only eDirectory Users and Groups 


For OES 2 Linux services, the LUM technology eliminates the need for local users and groups. We 
recommend, therefore, that you avoid the problems discussed in this section by not creating local 
users and groups. 


6.2 ConsoleOne Can Cause JClient Errors 


If you need to use ConsoleOne? to manage services on OES 2, make sure you have installed version 
1.3.6h or later. 


Earlier versions of ConsoleOne cause JClient errors in iManager. 
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6.3 CUPS on OES 2 Linux 


iPrint is the print solution for OES 2 Linux and offers more robust and scalable print services than a 
CUPS installation can. iPrint actually uses CUPS to render print jobs prior to sending them to the 
printer, but for scalability and performance, printing from the server itself is disabled during iPrint 
installation. 


If you plan to use iPrint, deselect Print Server in the Primary Functions category during the install 
and don’t configure CUPS on the OES 2 Linux server. 


6.4 eDirectory 


* Section 6.4.1, “Avoid Uninstalling eDirectory,” on page 62 

* Section 6.4.2, “Avoid Renaming Trees and Containers,” on page 62 

* Section 6.4.3, “One Instance Only,” on page 62 

* Section 6.4.4, “Default Static Cache Limit Might Be Inadequate,” on page 63 


* Section 6.4.5, “Special Characters in Usernames and Passwords,” on page 63 


6.4.1 Avoid Uninstalling eDirectory 


OES services are tightly integrated with eDirectory and do not function without it. 


Although the eDirectory 8.8 documentation describes how to remove and reinstall eDirectory, the 
processes described do not cleanly decouple OES services, nor do they restore service connections. 
As a result, not only does uninstalling eDirectory break OES services, reinstalling eDirectory does 
not restore them. 


If you have an issue that you believe can ony be resolved by uninstalling eDirectory, make sure you 


consult with Novell Technical Services before you attempt to do so. 


6.4.2 Avoid Renaming Trees and Containers 


The configuration files for many OES services point to configuration data stored within eDirectory. 


Although eDirectory tracks all changes internally, OES services do not. Therefore, if you rename 
your eDirectory tree or one of the containers below [Root], you should expect that one or more of 
your OES services will break. 


If you need to rename a container or tree, make sure that you 


1. Identify all of the configuration files for your OES services. 
2. Assess whether the changes that you are planning impact any of your service configurations. 


3. Understand and articulate the changes that are required to restore your services after renaming. 


There are no automated tools in OES for resolving the configuration errors and other problems that 
are caused by renaming a tree or its containers. 


6.4.3 One Instance Only 


OES 2 supports only one instance of eDirectory (meaning one tree instance) per server. 
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If you need two or more instances running on a single server, you must install them on a non-OES 
server, such as SLES 10. 


6.4.4 Default Static Cache Limit Might Be Inadequate 


The eDirectory install in OES 2 SP1 Linux sets a default static cache of 64 MB if an_ndsdb. ini 
file is not present in the dib directory. 


To improve performance, you can adjust the cache parameter in the ndsdb. ini file after the install 
to meet your eDirectory performance requirements, depending on the database size and available 
system RAM. We recommend setting the cache to 200 MB on a2 GB RAM system and 512 MB on 
4 GB RAM system. 


6.4.5 Special Characters in Usernames and Passwords 


Using special characters in usernames and passwords can create problems when the values are 
passed during an eDirectory installation or schema extension. 


If the username or password contains special characters, such as $, #, and so on, escape the character 
by preceding it with a backslash (\). For example, an administrator username of 


cn-admin$name.o-container 
must be passed as 
cn=admin\Sname.o=container 


When entering parameter values at the command line, you can either escape the character or place 
single quotes around the value. For example: 


cn=admin\$name.o=container 
or 


'cn-admin$name.o-container' 


6.5 iManager 2.7 


In “Installing RBS" in the Novell iManager 2.7.3 Administration Guide, you are instructed to run 
the iManager Configuration Wizard before using iManager. 


When iManager is installed in connection with OES 2, various roles and tasks are configured, as 
shown in Figure 6-1. 


These roles and tasks are available to all the users you create until you run the configuration wizard. 
After that, the roles and tasks are available only to the Admin user and other users or groups you 
specifically designate. 
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Figure 6-1 iManager Roles and Tasks 


i] Novell iManager 





© Roles and Tasks 
@ Available Novell Plug-in Modules 
[All Categories] X 


Novell Plug-in Modules are being extracted using InstallAnywhere program. 


Success: The plug-in module has been successfully installed. 


You must now restart Tomcat in order for the changes to take effect. 
After Tomcat restarts, if Role Based Services is installed you will need to 
configure the newly installed modules. 








File Protocols 


Files and Folders 








For more information on iManager, see the Novell iManager 2.7.3 Administration Guide. 


6.6 iFolder 3.8 


Implementation caveats for iFolder 3.8 are documented in “Caveats for Implementing iFolder 3.7 
and Later Services" in the Novell iFolder 3.8 Administration Guide. 


6.7 iPrint 


iPrint has the following implementation caveats: 


* Section 6.7.1, “Cluster Failover Between Mixed Platforms Not Supported," on page 64 


* Section 6.7.2, “Printer Driver Uploading on OES 2 Linux Might Require a CUPS 
Administrator Credential," on page 65 


* Section 6.7.3, "Printer Driver Uploading Support," on page 65 
* Section 6.7.4, “iManager Plug-Ins Are Platform-Specific,” on page 65 
* Section 6.7.5, “iPrint Client for Linux Doesn't Install Automatically," on page 65 


* Section 6.7.6, “iPrint Disables CUPS Printing on the OES 2 Linux Server,” on page 65 


6.7.1 Cluster Failover Between Mixed Platforms Not Supported 


Clustered iPrint services can only fail over to the same OES 2 platform (Linux or NetWare). 
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6.7.2 Printer Driver Uploading on OES 2 Linux Might Require a 
CUPS Administrator Credential 


A PPD is the Linux equivalent of a printer driver on Windows. 


There are two versions of the iPrint Client: high security and low security. By default, end users and 
administrators install the high-security client when using the iPrint Printer List Web page. 


This means that administrators are prompted for a CUPS administrator credential when uploading 
PPDs. However, the prompt doesn’t specify that a CUPS administrator credential is needed and the 
root user credential does not work. 


6.7.3 Printer Driver Uploading Support 


Uploading PPD printer drivers from a Linux workstation requires a Mozilla*-based browser. Only 
the Add From System button works for uploading drivers. Non-Mozilla-based browsers, such as 
Konqueror, cannot be used to upload drivers. 


Uploading PPD printer drivers from a Windows workstation requires Internet Explorer* 5.5 or later. 
Other browsers running on Windows do not work for uploading drivers. 


Windows printer drivers cannot be uploaded by using Mozilla-based or other browsers on any 
platform. 


6.7.4 iManager Plug-Ins Are Platform-Specific 


The iManager plug-ins are different for each server platform. Therefore, if you have both OES 2 
Linux and OES 2 NetWare servers running iPrint services, you need two instances of iManager to 
manage iPrint—one on each platform. 


6.7.5 iPrint Client for Linux Doesn't Install Automatically 


Users who are used to installing the Windows iPrint Client expect to choose an Open option and 
have the client install automatically. However, installing the client on Linux workstations requires 
you to save the RPM package and then install it manually if a package manager is not already 
installed and configured as it is in the Novell Linux Desktop. For more information, see “Linux: 
iPrint Client” in the OES 2 SP2: iPrint for Linux Administration Guide. 


6.7.6 iPrint Disables CUPS Printing on the OES 2 Linux Server 


iPrint uses CUPS to render print jobs before sending the print job to the Print Manager. For 
performance and scalability, printing from the server itself is disabled during the OES installation of 
iPrint. 


6.8 NCP Server (OES 2 Linux) 


NSS file attributes and NCP™ services tend to get mixed together in the minds of NetWare 
administrators. It is important to remember that file and directory attributes are supported and 
enforced by the file system that underlies an NCP volume, not by the NCP server. 
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For example, even though the Rename Inhibit attribute appears to be settable in the NCP client 
interface, if the underlying file system is Linux POSIX (Reiser, etc.) there is no support for the 
attribute and it cannot be set. 


Salvage (undelete) and Purge are other features that are available only on NSS and only where the 
Salvage attribute has been set (the NSS default). They can be managed in the NCP client and 
through NetStorage, but they are not available on NCP volumes where the underlying file system is 
Linux POSIX. 


Some administrators assume they can provide NSS attribute support by copying or migrating files, 
directories, and metadata from an NSS volume to a defined NCP volume on a Linux POSIX 
partition. However, this doesn’t work, because NSS file attributes are only supported on NSS 
volumes. 


6.9 NSS (OES 2 Linux) 


EVMS is the only supported volume manager for NSS volumes on OES 2 Linux. 


Although some administrators have successfully created NSS volumes on hard disks managed by 
non-EVMS volume managers, there are serious management and configuration limitations 
associated with this unsupported implementation. For more information, see “Using NSS on 
Devices Managed by Non-EVMS Volume Managers (Linux)" in the NW 6.5 SP8: NSS File System 
Administration Guide. 





NOTE: EVMS support is automatic and requires no manual configuration unless NSS is being 
installed on the device that contains the boot (/boot) and root (/) partitions (the system device). In 
that case only you must follow the instructions in “Installing with EVMS as the Volume Manager of 
the System Device” in the OES 2 SP2: Installation Guide. 





6.10 OpenLDAP on OES 2 Linux 


You cannot run OpenLDAP on an OES 2 Linux server with eDirectory installed. eDirectory LDAP 
is required for OES 2 services and uses the same ports as OpenLDAP. 


6.11 Samba 


For Samba implementation caveats, see “Samba Caveats” in the OF S2 SP2: Samba Administration 
Guide. 


6.12 Virtualization Issues 


The following are caveats for setting up OES 2 server in Xen VMs: 


* Section 6.12.1, “eDirectory Fails to Start Automatically,” on page 67 
* Section 6.12.2, “NSS Considerations,” on page 67 
* Section 6.12.3, “Always Use Timesync Rather Than NTP,” on page 67 
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6.12.1 eDirectory Fails to Start Automatically 


Although it is somewhat rare, if you install and configure OES 2 (specifically eDirectory) at the 
command prompt rather than through YaST, eDirectory might fail to start. If this happens, enter the 
following command at the command prompt: 


chkconfig -a ndsd 


6.12.2 NSS Considerations 


Make sure you follow these guidelines for using NSS volumes in connection with OES 2 servers 
running in Xen VMs: 


¢ Both Linux and NetWare Platforms: NSS pools and volumes must be created on only SCSI 
or Fibre Channel devices. You cannot use a file-based disk image, LVM-based disk image, or 
an SATA/IDE disk for the virtual machine. 


* OES 2 Linux: Data shredding is not supported. 


6.12.3 Always Use Timesync Rather Than NTP 


Time synchronization problems have been observed when virtualized NetWare servers are running 
the XNTPD NLM™. Therefore, Novell strongly recommends using Timesync and also configuring 
the service to communicate through NTP. 


6.13 Web Services 


The novell-tomcat package is installed for Novell service use only. It is an embedded part of 
Novell services, not a generic application platform. 


If you want to deploy a Web application on Tomcat on an OES server, install and use the Tomcat 
package that comes with SLES 10, not the novell-tomcat package. 
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Upgrading to OES 2 


This section provides information and links for upgrading to Open Enterprise Server. 


* Section 7.1, “Caveats to Consider Before Upgrading,” on page 69 
* Section 7.2, “OES 2 SPI Linux Upgrade Paths,” on page 70 
* Section 7.3, “OES 2 SP1 NetWare Upgrade Paths,” on page 70 


7.1 Caveats to Consider Before Upgrading 


Be aware of the following caveats when upgrading an OES server: 
¢ Section 7.1.1, “About Previously Installed Packages (RPMs),” on page 69 
* Section 7.1.2, “iManager 2.5 Replaced by iManager 2.7 on NetWare,” on page 69 
* Section 7.1.3, “OES 1 Linux to OES 2 Linux Service Differences," on page 69 
* Section 7.1.4, “Only One eDirectory Instance Is Supported on OES Servers," on page 70 
¢ Section 7.1.5, “Virtual Office from NetWare 6.5 to OES 2 NetWare,” on page 70 


7.1.1 About Previously Installed Packages (RPMs) 


Other Novell® products, such as GroupWise®, and third-party applications that you have installed 
are treated differently by default when you upgrade an OES Linux server, depending on the version 
of the server you are upgrading: 


+ OES I: Applications are deleted by default during an upgrade. 


* OES 2: Applications installed on an OES 2 server are retained, but might not work after 
upgrading. 


To learn more and for instructions on manually changing these options, see “Planning for the 
Upgrade to OES 2 SP2” in the OES 2 SP2: Installation Guide. 


7.1.2 iManager 2.5 Replaced by iManager 2.7 on NetWare 
If iManager 2.5 is installed on a NetWare server, and you apply OES 2 NetWare (NetWare 6.5 


Support Pack 8), iManager and its associated plug-ins are automatically updated to version 2.7. For 
more information about iManager 2.7, see the Novell iManager 2.7.3 Administration Guide. 


If you are using iManager 2.02, iManager is not upgraded. 


7.1.3 OES 1 Linux to OES 2 Linux Service Differences 


eGuide, Novell iFolder® 2, and Virtual Office are not supported on OES 2 Linux. If you upgrade an 
OES 1 Linux server with any of these installed to OES 2 SP1 Linux, the services cease to function. 
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7.1.4 Only One eDirectory Instance Is Supported on OES 
Servers 


If your OES server has multiple instances of eDirectory™ running (multiple trees), any attempt to 
upgrade the server fails. 


You must remove all instances, except the one that uses port 524, prior to an upgrade. 


For more information, see Section 6.4.3, “One Instance Only,” on page 62. 


7.1.5 Virtual Office from NetWare 6.5 to OES 2 NetWare 


All releases of OES NetWare to this point (except OES 1 SP1) have included Virtual Office 1.6. 
When you upgrade a NetWare 6.5 SP2 or earlier server to one of these support packs, any Virtual 
Office installations are automatically upgraded to version 1.6. 


When you upgrade an existing Virtual Office installation, all data, teams, configurations, etc. are 
retained with the following exceptions: 


* User Bookmarks are lost 
* E-mail notifications might need to be reconfigured 


* Team File Share credentials might need to be re-created. 


7.2 OES 2 SP1 Linux Upgrade Paths 


The following are supported upgrade paths for OES 2 SP1 Linux: 
Table 7-1 Supported OES 2 SP1 Linux Upgrade Paths 


Source Destination 


OES 1 SP2 32-bit (Latest Patch Level) (Physical OES 2 SP1 32-bit (Physical only) 





only) 
OES 2 32-bit (Physical or virtual) OES 2 SP1 32-bit (Physical or virtual) 
OES 2 64-bit (Physical or virtual) OES 2 SP1 64-bit (Physical or virtual) 





NOTE: Physical installations cannot be upgraded to virtual installations, and the reverse is also true. 
Only physical to physical and virtual to virtual upgrades are supported. 





For complete upgrade instructions, see “Upgrading to OES 2 SP2” in the OES 2 SP2: Installation 
Guide. 


In addition to upgrading the server itself, data and service migrations from OES 1 to OES 2 Linux 
are also supported. For more information, see the OES 2 SP2: Migration Tool Administration Guide. 


7.3 OES 2 SP1 NetWare Upgrade Paths 


The following are supported upgrade paths to OES 2 SP1 NetWare. 
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Table 7-2 Supported OES 2 SP1 NetWare Upgrade Paths 


Source Destination 


Physical NetWare 5.1 SP8 1. Upgrade to OES 1 SP2 NetWare (6.5 SP6). 
See “Upgrading to NetWare 6.5 SP6” in the 
NW65 SP8: Installation Guide. 


2. Upgrade to OES 2 SP1 NetWare (6.5 SP8). 
See “Upgrading to NetWare 6.5 SP8” in the 
NW65 SP8: Installation Guide. 





Physical OES 1 SP2 or OES 2 NetWare (6.5 SP6 Physical OES 2 SP1 NetWare (6.5 SP8). See 
or SP7) "Upgrading to NetWare 6.5 SP8” in the NW65 SP8: 
Installation Guide. 





Virtual OES 2 NetWare (6.5 SP7) Virtual OES 2 SP1 NetWare (6.5 SP8). See 
“Upgrading a NetWare 6.5 Guest on a Xen-based 
VM Host Server” in the NW65 SP8: Installation 
Guide. 


In addition to upgrading the physical server itself, data and service migrations from NetWare to OES 
2 Linux are also supported. For more information, see the OES 2 SP2: Migration Tool 
Administration Guide. 
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Migrating and Consolidating 
Existing Servers and Data 


This section briefly outlines the following migration topics: 


* Section 8.1, “Supported OES 2 SP1 Migration Paths," on page 73 


* Section 8.2, “Migration Tools and Purposes,” on page 73 


8.1 Supported OES 2 SP1 Migration Paths 


For a complete list of Open Enterprise Server 2 SP1 migration scenarios and paths, see “Migration 
Scenarios” in the OES 2 SP2: Migration Tool Administration Guide. 


8.2 Migration Tools and Purposes 


The following sections briefly explain the purpose of each migration tool/utility included in OES 2 
SPI: 

* Section 8.2.1, “OES 2 SPI Migration Tool," on page 73 

è Section 8.22, “Migrate Windows Shares Utility,” on page 73 

* Section 8.2.3, “NetWare Migration Wizard," on page 74 

* Section 8.2.4, "Server Consolidation Utility," on page 74 


8.2.1 OES 2 SP1 Migration Tool 


The OES 2 SP1 Migration Tool lets you migrate and/or consolidate data and services from one or 
more NetWare, OES 1, or OES 2 source servers to an OES 2 SP1 Linux target server. The source 
servers must each be running the same platform. Cross-platform consolidations are not directly 
supported, but can be facilitated as explained in “Cross-Platform Data Consolidations" in the OES 2 
SP2: Migration Tool Administration Guide. 


You can also transfer a complete server identity, including its IP address, hostname, eDirectory 
identity, NICI keys, and certificates. For more information, see “Transfer ID " in the OES 2 SP2: 
Migration Tool Administration Guide. 


8.2.2 Migrate Windows Shares Utility 


To help you migrate data from Windows NT*, 2000, or 2003 servers to OES 2 SP1 Linux, OES 2 
SP1 includes the Migrate Windows Shares utility. 


For more information, see "Migrating Data from Windows to OES 2 SP2 Linux" in the OES 2 SP2: 
Migration Tool Administration Guide. 
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8.2.3 NetWare Migration Wizard 


The primary purposes of the Novell® NetWare® Migration Wizard are 


+ To migrate NetWare servers to OES 2 SP1 NetWare (6.5 SP8) and/or to new hardware. 


+ To facilitate migrations from older versions of NetWare to NetWare 5.1 SP8, in preparation for 
migrating to OES 2 SP1 Linux. 


After migrating to NetWare 5.1 SP8, servers can then be migrated using the OES 2 SP1 
Migration Tool. 


When the migration is complete, the new NetWare server replaces and assumes the identity of the 
old NetWare server on the network. 


The supported migration paths to OES 2 SP1 NetWare (6.5 SP8) are listed in “NetWare Migration 
Wizard” in the Novell Server Consolidation and Migration Toolkit Administration Guide. 


8.2.4 Server Consolidation Utility 


The primary purpose of the Server Consolidation Utility is to migrate and consolidate: 


* Users 
* File permissions 
* Passwords 


* File Systems 


from existing NetWare servers to OES 2 NetWare (6.5 SP8) servers. 





NOTE: If you are moving a NetWare server to new hardware, use the NetWare Migration Wizard 
instead. 





The Server Consolidation Utility can also be used to 


+ Migrate NetWare servers to OES 2 SP1 Linux. However, the primary tool for this purpose is 
the OES 2 SP1 Migration Tool. 


* Migrate and consolidate some Windows servers. However, certain restrictions apply as 
explained in “Server Consolidation Utility” in the Novell Server Consolidation and Migration 
Toolkit Administration Guide. The primary tool for migrating Windows shares to OES 2 SP1 
Linux is the Migrate Windows Shares Utility. 


For more information, see “Server Consolidation and Migration Overview” in the Novell Server 
Consolidation and Migration Toolkit Administration Guide. 
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Virtualization in OES 2 


In Open Enterprise Server 2, you can host multiple OES 2 servers on Xen virtual machines (VMs) 
on a single Xen host server (either OES 2 Linux or SUSE® Linux Enterprise Server 10 SP1). 


For information about installing and running OES 2 services on Xen-based virtual machines, see the 
links on the Virtualization page of the OES 2 Online Documentation. 


* Section 9.1, “Graphical Overview of Virtualization in OES 2,” on page 75 
* Section 9.2, “Why Install OES Services on Your VM Host?,” on page 76 
* Section 9.3, "Services Supported on VM Hosts and Guests,” on page 76 





IMPORTANT: Although OES 2 NetWare? and NetWare 6.5 share the same code base and are the 
same in every way, virtualized NetWare in Xen is an OES 2 product feature. Support for NetWare on 
a Xen virtual machine is available only to OES 2 registered customers. 





9.1 Graphical Overview of Virtualization in OES 2 


Figure 9-1 illustrates how a single VM host server can support multiple VM guest servers that in 
turn provide OES services. 


Figure 9-1  Xen-Based Virtualization in OES 2 
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9.2 Why Install OES Services on Your VM Host? 


Novell supports three OES 2 services running on a Xen VM host server: Novell Linux User 
Management, Novell Storage Management Services, and Novell Cluster Services™. Additionally, 
whenever you specify OES 2 as an add-on product, the YaST-based NetWare Response File Utility 
is automatically installed, whether you install any services or not. 


Having these components installed on a Xen VM host server provides the following benefits: 


* Linux User Management (LUM): Lets you SSH into the server for management purposes by 
using an eDirectory™ user account. 


This functionality requires that you 
* Enable SSH communications through any firewalls that are running on the server 


* Configure LUM to allow SSH as a LUM-enabled service. For more information see “SSH 
Services on OES 2" in the OES 2 SP2: Planning and Implementation Guide 


* Storage Management Services (SMS): Lets you back up the VM host server and all of the 
VM guests. 


* Novell Cluster Services (NCS): Lets you cluster the VM guests running on the VM host. 


* NetWare Response File Utility: Lets you pre-answer the same questions as you would during 
a physical NetWare installation. When the time comes to run the NetWare Install program, the 
installation reads your responses from the file and proceeds without requiring further 
intervention. 


9.3 Services Supported on VM Hosts and Guests 


As you plan your virtualization configurations, you will want to consider which services are 
supported where Table 9-1 and which combinations of services are supported (see Section 3.10.15, 
“Unsupported Service Combinations,” on page 41). 


Table 9-1 Services Supported on VM Hosts and Guests 


OES 2 Service Linux VM Host Linux VM Guest NetWare VM Guest 
AFP (Novell AFP) 
Backup/SMS Y 
CIFS (Novell CIFS) 


Cluster Services Y (non-NSS and Xen 
templates only) 


DHCP 


5 <5 4 


DNS 


Domain Services for 
Windows (DSfW) 


eDirectory 


LA AK X XS X 


UN 


FTP 
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OES 2 Service Linux VM Host Linux VM Guest NetWare VM Guest 


Novell iFolder® ¥ (3.7) v/ (2.1x) 
iManager Y Y 

iPrint Y 
Linux User Management Y 


NCP Server/Dynamic 
Storage Technology 


Novell Remote Manager 
(NRM) 


Novell Storage 
Services™ (NSS) 


Y 
Y 
Y 
NetStorage Y 
Y 
Y 
Y 


HEUS 


QuickFinder™ 


Samba Y 





IMPORTANT: Adding OES services to a Xen VM host requires that you boot the server with the 
regular kernel prior to adding the services. See the instructions in the Important note in Installing or 
Configuring OES Services on an Existing Server" in the OES 2 SP2: Installation Guide. 
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Clustering and High Availability 


Open Enterprise Server 2 includes support for a two-node Novell® Cluster Services™ cluster. 


The full Novell Cluster Services product (available through a separate purchase) is a multinode 
clustering product that 

* Can include up to 32 servers. 

* Is available for both NetWare® and Linux. 

¢ Is eDirectory™ enabled for single-point ease of management. 


¢ Supports failover, failback, and migration (load balancing) of individually managed cluster 
resources. 


* Supports shared SCSI, iSCSI, and Fibre Channel storage area networks. 


For more information, see the topics in “NetWare 6.5 SP8” in the OES 2 online documentation. 
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Managing OES 2 


This section includes the following topics: 
* Section 11.1, “Overview of Management Interfaces and Services," on page 81 
* Section 11.2, “Using OES 2 Welcome Pages,” on page 82 
* Section 11.3, “OES Utilities and Tools," on page 83 
* Section 11.4, “SSH Services on OES 2 Linux,” on page 96 


11.1 Overview of Management Interfaces and 
Services 


As shown in Figure 11-1, Open Enterprise Server provides a rich set of service-management and 
server-management tools, including browser-based and server-based interfaces that help you 
implement and maintain your network. Access to most of these management interfaces is controlled 
through eDirectory™. However, a few interfaces, such as YaST on SUSE® Linux Enterprise Server 
10 servers, require local authentication. 


For more information, see Section 11.3, “OES Utilities and Tools,” on page 83. 


Figure 11-1 Management Interfaces and Services 
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11.2 Using OES 2 Welcome Pages 


After you install an OES 2 server, anyone with browser access to the server can access its Welcome 
Web site, which is a collection of dynamic Web pages that provides the features illustrated and 
explained in Figure 11-2. 


Figure 11-2 The Default OES Welcome Page 
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This section explains OES Welcome Web Site features, and discusses: 


* Section 11.2.1, "The Welcome Site Requires JavaScript, Apache, and Tomcat," on page 82 
* Section 11.2.2, “Accessing the Welcome Web Site," on page 83 

* Section 11.2.3, “The Welcome Web Site Is Available to All Users," on page 83 

* Section 11.2.4, “Administrative Access from the Welcome Web Site,” on page 83 


11.2.1 The Welcome Site Requires JavaScript, Apache, and 
Tomcat 


Browsers accessing the Welcome site must have JavaScript* enabled to function correctly. 


Additionally, it is possible to install OES 2 on either supported platform without including the 
Apache Web Server or the Tomcat Servlet Container. For example, if you install OES 2 NetWare? 
by using the Customized NetWare Server option, neither of these components is selected by default. 
For OES 2 Linux, the Apache server and Tomcat container are included with many of the server 
patterns, but not all of them. 


If you are unable to access the Welcome Web site, your server is probably missing one or both of 
these required components. To make the site available, you need to add the components to the OES 
2 server. 
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11.2.2 Accessing the Welcome Web Site 


Anyone with browser access to an OES 2 server can access the Welcome site by doing the 
following: 


1 Open a supported Web browser that has a TCP connection to the network where the OES 2 
server is installed. 

2 Enter the URL to the server, using HTTP. 
For example: 


http://server.example.com/welcom 





or 


http://192.168.1.206/welcome 





IMPORTANT: By default, the Welcome site is accessible by entering only the DNS name or 
IP address without the path to /welcome as the URL. However, this behavior changes as 
follows: 


*On NetWare, the sys: /apache2/htdocs/index.html file redirects requests to the 
Welcome site page. If the file is changed, then the behavior reflects the changes made. 


*On Linux, the Welcome site displays only when there is no index.html file in /srv/www/ 
htdocs. For example, installing the Web and LAMP Server pattern installs a page that 
says “It Works!” and the Welcome site is not displayed. 


In these cases the complete path is required (including /welcome) to access the Welcome site. 





11.2.3 The Welcome Web Site Is Available to All Users 


Although the Welcome Web site is designed primarily for administrators, it can also be accessed and 
used by end users. For example, if iPrint is installed on the server, users can install the iPrint Client 
by clicking the Client Software link and selecting the appropriate client. 


11.2.4 Administrative Access from the Welcome Web Site 


Administrators can access any of the administrative tools installed on the server by clicking the 
Management Services link, selecting the tool they want to use, and entering the required 
authentication information. 


11.3 OES Utilities and Tools 


Novell® OES 2 includes several administration utilities that let you manage everything in your 
network, from configuring and managing eDirectory to setting up network services and open source 
software. This section lists and briefly explains the most common utilities. 


Whenever possible, we recommend that all OES management be performed by using browser-based 
tools. This ensures that all the system commands required to execute various tasks are performed in 
proper order and that none of them is skipped by mistake. 


Table 11-1 is a quick reference for accessing information about the OES management tools. Specific 
instructions for the tasks listed are located in the administration guides and other documentation for 
the services that each tool manages. 
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Table 11-1 OES Management Tool Quick Reference 


Access Method or URL/ 


Tool Tasks Notes 
Username 
Apache Manager ¢ Control one or many To access Apache Runs only from NetWare, but 
Apache Web servers Manager from the can configure Apache Web 
on any platform from Welcome Web site: servers on multiple platforms. 
a single 


management 1. Open the Welcome For more information on 
interface. Web site on an OES using Apache Manager, see 
2 NetWare server the NW 6.5 SP8: Apache 
i Greatly reduce the using your server's Web Server Administration 
risk of configuration URL. For example, Guide. 
errors. http:// 
myserver.example.c 
om. 


2. Login as the 
eDirectory Admin 
user. 


3. In the left frame, 
click the [+] icon 
next to Open 
Source, then click 
Apache 2.0. 


4. After the Apache 2.0 
Welcome page 
loads, in the upper 
right link box, click 
either Administer 
Single Apache 
Server or 
Administer Multiple 
Apache Servers. 





bash (Linux) * Manage the Linux Access a command For more information or help 
server. prompt on the Linux understanding and using 
server. bash, search the Web for any 
of the numerous articles and 
tutorials on using the shell. 


* Manage many 
services running on 


the server. 
BASH (NetWare) + Perform asubset of To start the shell at a To learn more about using the 
BASH commands. NetWare console prompt, BASH commands on 
enter NetWare, see the man pages 
available at the command 
bash.nlm prompt by entering 
man bash 


For more information, see 
"BASH" in the NW 6.5 SP8: 
Utilities Reference. 


To obtain the source files for 
this version of BASH on 
NetWare, visit 
forge.novell.com (http:// 
forge.novell.com). 
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Access Method or URL/ 











Tool Tasks Notes 
Username 
® . . 
ConsoleOne + Manage eDirectory 1. Do either of the IMPORTANT: If you are 
(NetWare) objects, schema, following: From a : 
ex : running ConsoleOne on a 
partitions, and workstation, map a À 
] : server that runs iManager 
replicas. drive to the : 
NetWare server and 2.7, you must install 
+ Manage NetWare rn ConsoleOne 1.3.6h or later. 
Server resources. Otherwise, iManager will 
consoleone.exe : s 
experience JClient errors. 
from 
Sys: publicVMngm : . 
+\consoleone\1. For more information about 
2\bin. or From a ConsoleOne, see the 
NetWare server ConsoleOne 1.3.x User 
console, click the Guide. 
Novell menu and 
select ConsoleOne 
from the list of 
options. 
2. Specify the 
eDirectory Admin 
username and 
password. 
Health * Monitor the health of 1. In a supported Web Functionality is limited for 
Monitoring Linux or NetWare browser, access non-Admin or non-root 
Services servers. Novell Remote users on both platforms. 
Manager by i : 
entering http:// NRM on Linux doesn't include 
IP Address:8008 all the functionality of NRM on 
<a NetWare. 
2. Specify the 
eDirectory Admin For more information, see the 
username and NW 6.5 SP8: Novell Remote 
password, or on Manager Administration 
Linux you can use Guide or the OES 2 SP2: 
the root userand Novell Remote Manager for 
password if needed. Linux Administration Guide. 
3. Click Health Monitor 


under Diagnose 
Server. 


Health Monitoring Services 
on OES 2Linux use a 
Common Information Model 
(CIM) provided by the Web- 
Based Enterprise 
Management (WBEM) 
Initiative. For more 
information on WBEM, visit 
the DMTF Web site (http:// 
www.dmtf.org/standards/ 
wbem). 
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Access Method or URL/ 


Tool Tasks Notes 
Username 
iManager 2.7 * Access various other 1. In a supported Web Requires an SSL connection 
management tools browser, enter the (HTTPS). 
and plug-ins. following URL: Bondi EIUS 
i [o an 
* Configure OES http:// requests establish the SSL 
network services. IP or DNS/ connection. 
* Create and manage iManager.html F = i 
or more information on 
BU rene 2. Specify the using iManager, see the 
pene eDirectory Admin Novell iManager 2.7.3 
* Delegate username and Administration Guide. 
administration password. 
through Role-Based See also iManager 
Services (RBS). Workstation. 


* Manage eDirectory 
objects, schema, 
partitions, and 
replicas. 


* Manage NetWare 6.5 
servers. 


* Manage OES2 
services on both 
Linux and NetWare. 


* Setup and manage 
your Novell 
eDirectory tree. 
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Access Method or URL/ 





Tool Tasks semana Notes 
iManager + Manage eDirectory. Ona Linux workstation: | Requires an SSL connection 
Workstation HTTPS). 
(formerly Mobile * Create and ias 1. Atthe bin directory i 
iManager) users; groups, an of the expanded Both HTTP and HTTPS 
other objects: iMan 25 Mobile requests establish the SSL 
* Manage OES2 iManager linux. connection. 
services. tar directory, run F "S i 
, or more information on 
* Access various other ML M: using iManager Workstation, 
management tools 2. Login, using the see "Accessing iManager 
and plug-ins. eDirectory Admin ^ Workstation” in the Novell 
username, iManager 2.7.3 
password, and Administration Guide. 
eDirectory tree 
name. See also iManager. 
On a Windows 
workstation: 
1. Atthe bin directory 
of the unzipped 
iMan 25 Mobile_ 
iManager win 
directory, run 
imanager.bat. 
2. Log in, using the 
eDirectory Admin 
username, 
password, and 
eDirectory tree 
name. 
iMonitor * Monitor and 1. In a supported Web  iMonitor provides a Web- 
diagnose all the browser, enter one based alternative to tools 
servers in your of the following such as DSBrowse, DSTrace, 
eDirectory tree. URLs: DSDiag, and the diagnostic 
; ; features available in 
+ Examine eDirectory (On NetWare) DSRepair. 
partitions, replicas, http:// 
and servers. IP or DNS:81/ Because of this, iMonitor’s 
* Examine current nds — features are primarily server 
tasks taking place in focused, meaning that they 
the tree. (On Linux) report the health of individual 
https:// eDirectory agents (running 
IP or DNS:8030/ instances of the directory 
nds service) rather than the entire 
2. Specify the eDirectory tree. 


eDirectory Admin 
username and 
password. 


For more information, see 
"Using Novell iMonitor 2.4" in 
the Novell eDirectory 8.8 
Administration Guide. 
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Access Method or URL/ 








Tool Tasks Notes 
Username 
INETCFG Manage network and 1. Load the inetcfg For more information, see 
(NetWare) server TCP/IP NLM™ ata "INETCFG' in the NW 6.5 
communications. NetWare System SP8: Utilities Reference. 
Manage IP Console prompt. 
addresses. 2. Access the server 
Bind boards on a console. 
NetWare server. 3. Toggle to the 
Screen. 
IP Address Manage the IP 1. In a supported Web For more information, see the 
Manager address-application browser, enter the NW 6.5 SP8: IP Address 
(NetWare) association when following URL: Management Administration 
changing the Guide. 
NetWare server's IP https:// 
address. IP or DN3:8009/ 
ipmcfg 
Resolve IP address . 
and port conflicts. 2. Specify the 
eDirectory Admin 
username and 
password. 
iPrint Map Create a printer map 1. In a supported Web For OES 2 Linux server 
Designer to aid in printer browser, enter the ^ instructions, see "Setting Up 
selection/installation. following URL: Location-Based Printing" in 
; eH the OES 2 SP2: iPrint for 
Edit an existin 
interma 9 http:// Linux Administration Guide. 
P P. IP or DNS/ 
ippdocs/ For OES 2 NetWare server 
maptool.htm instructions, see "Setting Up 
; Location-Based Printing" in 
2. Specify the the NW 6.5 SP8: iPrint 
eDirectory Admin mh : : 
Administration Guide. 
username and 
password. 
MySQL 4.0 Create and manage 1. In a supported Web For more information, see the 
(phpMyAdmin) MySQL databases. browser, enter the NW 6.5 SP8: Novell MySQL 
(NetWare) Monitor processes. following URL: Administration Guide. 
Export databases. https:// 
Create and manage ROM N ~ 
user accounts. PhP"Y a 
index.php 
2. Specify the 
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eDirectory Admin 
username and 
password. 


Access Method or URL/ 








Tool Tasks Notes 
Username 
NetStorage Web + Manage file system Use the NetStorage Web As an Admin user (or 
Interface access. interface. equivalent), you can set 
* Manage file system directory and user quotas for 
space restrictions. NSS data volumes. You can 
also set file system trustees, 
* Salvage and purge trustee rights, and attributes 
deleted files. for directories and files on 
NSS volumes. And you can 
salvage and purge deleted 
files. 
For more information, see 
either of the following: 
* "Viewing or Modifying 
Directory and File 
Attributes and Rights" in 
the OES 2 SP2: 
NetStorage for Linux 
Administration Guide. 
* “Viewing or Modifying 
Directory and File 
Attributes and Rights” in 
the NW 6.5 SP8: 
NetStorage 
Administration Guide. 
NetWare * Manage and Enter the commands at For more information, see the 
Command Line configure all aspects the server console or NW 6.5 SP8: Utilities 
Utilities of the NetWare through a remote Reference. 
operating system. connection. 
* Manage many of the 
network services that 
NetWare hosts. 
Novell Client + Manage file system Use the Novell N icon to As an Admin user (or 


access. 


* Manage File System 
Space Restrictions. 


* Salvage and purge 


deleted files. 


access these and other 
tasks. 


equivalent), you can set 
directory and user quotas for 
NSS data volumes. You can 
also set file system trustees, 
trustee rights, and attributes 
for directories and files on 
NSS volumes. And you can 
salvage and purge deleted 
files. 


For more information, see 
"Managing File Security and 
Passwords” in the Novell 
Client 4.91 SP5 for Windows 
XP/2003 Installation and 
Administration Guide. 
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Access Method or URL/ 





Tool Tasks Notes 
Username 
Novell iFolder® * Manage various 1. In iManager 2.7, For more information on 
3.7 aspects of iFolder click iFolder 3.7 > managing iFolder 3.7, see the 
3.7. Launch iFolder following in the Novell iFolder 
Admin Console. 3.8 Administration Guide: 
¢ iFolder Enterprise 
Server 
* iFolder Services via 
Web Admin 
¢ iFolder Users 
* iFolder Web Access 
Server 
* Managing iFolders 
Novell Remote * Manage file system 1. In a supported Web Functionality is limited for 
Manager (NRM) access and attributes browser, enter the — non-Admin or non-root users 


for the NetWare 
Traditional File 
System and the NSS 
File System on 
NetWare. 


* Manage the NCP™ 
Server (Linux) 


* Manage NCP 
connections to NSS 
and NCP volumes 
(Linux) 

* Manage Dynamic 
Storage Technology 
(Linux) 

* Manage NetWare 
Traditional File 
Systems (NetWare). 


* Manage OES2 
servers from a 
remote location. 


* Monitor your server's 
health. 


* Change server 
configurations. 


* Perform diagnostic 
and debugging tasks. 


* View volume 
inventories (Linux) 
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following URL: 


https:// 
IP or DNS:8009 


Do one of the 
following: 


* On NetWare, 
specify the 
eDirectory 
username and 
password. 


* OnLinux, 
specify either 
the eDirectory 
username and 
password or a 
Linux (POSIX) 
username and 
password. 


on both platforms. 


NRM on Linux doesn't include 
all the functionality of NRM on 
NetWare. 


For more information, see the 
NW 6.5 SP8: Novell Remote 
Manager Administration 
Guide or the OES 2 SP2: 
Novell Remote Manager for 
Linux Administration Guide. 


Tool 


NSS 
Management 
Utility (NSSMU) 


Tasks 


* Manage the Novell 
Storage Services™ 
file system. 


Access Method or URL/ 
Username 


At the NetWare System 
Console prompt: 


1. Load the NSSMU 
NLM. 


2. Access the server 
console. 


3. Toggle to the 
Screen. 


At the Linux command 
prompt: 


1. Load NSSMU by 
entering 


/opt/novell/ 
nss/sbin/nssmu 


Notes 


NSS Management Utility 
(NSSMU) is a server console 
application used to manage 
the Novell Storage System 
(NSS) logical file system. 


The Snapshot function in 
NSSMU on Linux is not 
available in NSSMU on 
NetWare. Use iManager to 
create snapshots for NetWare 
or Linux. 


For more information, see 
“NSS Management Utility 
(NSSMU) Quick Reference” 
in the NW 6.5 SP8: NSS File 
System Administration Guide. 





OpenSSH (client 
access) 


* Securely run 
commands on 
remote servers. 


* Securely copy files 
and directories to 
and from other 
servers using SSH 
utilities. 


Connect to the server 
using your favorite SSH 
client. 


On Linux, OpenSSH is 
installed by default and is 
accessed by eDirectory users 
as a LUM-enabled service. 
For more information, see 
Section 11.4, “SSH Services 
on OES 2 Linux," on page 96. 


On OES 2 NetWare, load 
sshd.nlmat the server 
console. 


To use OpenSSH from a 
workstation on your network, 
you must download one of 
several available third-party 
SSH utilities, such as PuTTy. 
For more information, see 
“Setting Up SSH at 
Workstations" in the NW 6.5 
SP8: OpenSSH 
Administration Guide. 





OpenSSH 
(Linux) 


* Manage a SLES 10 
SP1 (OES 2) server 
by using OpenSSH. 


1. Use standard SSH 
connection and 
management 
options. 


Requirements: 


* The firewall must allow 
for SSH access. 


¢ eDirectory users must 
be enabled for SSH 
access. For more 
information, see 
Section 11.4, “SSH 
Services on OES 2 
Linux,” on page 96. 
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Access Method or URL/ 








Tool Tasks Notes 
Username 

OpenSSH * Manage OpenSSH 1. In a supported Web For more information, see 

Advanced Admin Servers as server browser, enter the “Setting Up OpenSSH in Your 

(NetWare) groups. following URL: Network" in the NW 6.5 SP8: 

OpenSSH Administration 
https:// Guide. 
IP or DNS:2200/ 
sshdadmin/ 
main.htm 
2. Specify the 
eDirectory Admin 
username and 
password. 

OpenSSH * Manage all aspects 1. In a supported Web For more information, see 

Simple Admin of a single OpenSSH browser, enter the “Setting Up OpenSSH in Your 

(NetWare) server. following URL: Network" in the NW 6.5 SP8: 

OpenSSH Administration 
https:// Guide. 
IP or DNS:2200/ 
sshdadmin/ 
WebMan?file-web 
man.xml 
2. Specify the 
eDirectory Admin 
username and 
password. 

OpenWBEM * Perform tasks On NetWare, access For more information, see the 
instrumented by sys\system\cimom\e NW 6.5 SP8: OpenWBEM 
specific providers. tc\openwbem\openwb Services Administration 

em.conf. Guide. 
On Linux, access /etc/ 
openwbem. 
Perl A programming language On Linux, install the For more information or help 
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developed by Larry Wall 


that 


* 


Runs faster than 
shell script programs. 


Reads and writes 
binary files. 
Processes very large 
files. 


Lets you quickly 
develop CGI 
applications. 


associated RPM files. 


On NetWare, refer to the 
instructions on the Novell 
Developer Web site 
(http:// 
developer.novell.com/ 
wiki/index.php/ 

Perl for NetWare). 


understanding and using Perl, 
search the Web. There are 
numerous articles and 
tutorials on using this 
versatile programming 
language. 


Tool Tasks 


* Create search 
indexes for any Web 
site or attached file 
systems. 


QuickFinder™ 
Server Manager 


* Modify the search 
dialog look-and-feel 
to match your 
corporate 
design.Create full- 
text indexes of 
HTML, XML, PDF, 
Word, 
OpenOffice.org, and 
many other 
document formats. 


* Configure and 
maintain your 
indexes remotely 
from anywhere on 


Access Method or URL/ 
Username 


1. In a supported Web 
browser, enter the 
following URL: 


http:// 
IP or DNS/ 
qfsearch/admin 


2. Doone of the 
following: 


* On NetWare, 
specify the 
eDirectory 
Admin user 
and password. 


* OnLinux, 
specify the 
root or other 
user as 
documented. 


Notes 


Local users and any 
eDirectory users that are 
enabled for Linux access 
(LUM) can be assigned rights 
to manage QuickFinder. 


For more information, see the 
QuickFinder 5.0 Server 
Administration Guide. 





the Net. 
RConsoleJ * Access NetWare 
(NetWare) servers remotely. 


* Run server utilities 
from a workstation. 


1. Load the rconag6 
NLM™ on the 
NetWare server. 


2. At a workstation, 
map a drive to the 
server and run 
rconj.exe from 
sys: \public\mgm 
t\consoleone\l. 
2 


3. When prompted, 
enter the server's IP 
address or DNS 
name (with no 
leading protocol 
identifier, such as 
http or https) and 
your administrator 
password, then click 
Connect. 


For more information, see 
"Managing NetWare Servers 
Remotely” in the NW 6.5 SP8: 
Remote Server Management 
Administration Guide. 





Remote 
Manager 


See Novell Remote Manager. 
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Access Method or URL/ 





Tool Tasks Notes 
Username 
SNMP for Lets you use standard 1. Configure SNMP for SNMP support is installed 
eDirectory SNMP tools to eDirectory as with eDirectory. 
documented for 
* Monitor an your platform. For more information on 
eDirectory server. SNMP for eDirectory, see 
2. Access SNMP for «SNMP Support for Novell 
* Track the status of eDirectory services ; "d 
eDirectory to verify ina the SNMP eDirectory" in the Novell 
nbrmalopstations using tne eDirectory 8.8 Administration 
: management Guide. 
* Spot and react to interface of your 
potential problems choice. 
when they are 3. Specify the 
detected. eDirectory Admin 
* Configure traps and username and 
statistics for selective password. 
monitoring. 
* Plot a trend on the 
access of eDirectory. 
* Store and analyze 
historical data that 
has been obtained 
through SNMP. 
* Usethe SNMP native 
master agent on all 
eDirectory platforms. 
SUSE? Linux * Manage the Linux Enter the desired For more information, see 
Monitoring server and standard command at the "System Monitoring Utilities" 
Utilities Linux services from | command prompt. (http://www.novell.com/ 


the command 
prompt. 
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documentation/sles 10/ 

book sle reference/data/ 
cha util.html) in the SUSE 
Linux Enterprise Server 10 
SP3 Installation and 
Administration Guide (http:// 
www.novell.com/ 
documentation/sles 10/ 

book sle reference/data/ 
book sle reference.html). 


Access Method or URL/ 








Tool Tasks Notes 
Username 
TCP/IP Add a new network 1. In a supported Web For more information, see 
Configuration card. browser, enter the “Monitoring TCP/IP 
(NetWare - Associate TCP/IP following URL: Information" in the NW 6.5 
NRM) : : SP8: TCP/ IP Administration 
with a specific https:// : 
Guide. 
network card. IP or DNS:8009/ 
Edit system files. webcfg 
Enable and configure — 2. Specify the 
TCP/IP. eDirectory Admin 
Configure network usemame ang 
management password. 
parameters. 
Copy configuration 
information to or from 
a diskette. 
Modify the hardware 
parameters of an 
existing network 
card. 
TCP/IP Protocol Monitor protocol 1. In a supported Web For more information, see 
Information information. browser, enter the “Web-Based TCP/IP 
(NetWare - following URL: Monitoring ” in the NW 6.5 
NRM) SP8: TCP/ IP Administration 
https: // Guide. 
IP_or_DNS:8009/ 
protocols 
2. Specify the 
eDirectory Admin 
username and 
password. 
Tomcat Admin * Manage the Tomcat 1. In a supported Web For more information, see 
(NetWare) servlet container on a browser, enter the “Managing Web Applications 
NetWare server. following URL: and Servlets" in the NW 6.5 
SP8: Tomcat Administration 
https:// Guide. 
IP or DNS/ 
tomcat/admin/ 
index.jsp 
2. Specify the 


eDirectory Admin 
username and 
password. 
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Access Method or URL/ 





Tool Tasks Notes 
Username 
Tomcat Manager * Install and deploy 1. In a supported Web For more information, see 
(NetWare) Web applications. browser, enter the “Managing Tomcat with 
following URL: Tomcat Admin" in the NW 6.5 
SP8: Tomcat Administration 
http:// Guide. 
IP or DNS/ 
tomcat/manager/ 
html/list 
2. Specify the 
eDirectory Admin 
username and 
password. 
YaST (SUSE * Install OES 2 Linux. To access YaST fromthe For more information, see 
Linux) * Configure the server GNOME? interface, start “Installation with YaST” (http:/ 
and standard Linux the YaST Control Center /www.novell.com/ 
sarvicas: by clicking Computer > documentation/sles 10/ 
YaST. book sle reference/data/ 

* Install OES cha inst.html) and "System 
components and To access YaST ata Configuration with YaST" 
services. command prompt, enter — (http://www.novell.com/ 

yast. documentation/sles 10/ 


book sle reference/data/ 
cha yast2.html) in the SUSE 
Linux Enterprise Server 10 
SP3 Installation and 
Administration Guide (http:// 
www.novell.com/ 
documentation/sles 10/ 

book sle reference/data/ 
book sle reference.html). 


11.4 SSH Services on OES 2 Linux 


This section documents the following topics: 


* Section 11.4.1, "Overview," on page 96 


* Section 11.4.2, "Setting Up SSH Access for LUM-enabled eDirectory Users," on page 98 


11.4.1 Overview 


SSH (http://www.novell.com/company/glossary.html#4187) services on SLES 10 are provided by 
OpenSSH (http://www.openssh.org), a free version of SSH connectivity tools developed by the 
OpenBSD Project (http://www.openbsd.org/). 


Linux administrators often use SSH to remotely access a server for management purposes, such as 
executing shell commands, transferring files, etc. Because many OES 2 Linux services can be 
managed at a command prompt via an SSH session, it is important to understand how SSH access is 
controlled in OES 2 Linux. 
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This section discusses the following topics: 


* “When Is SSH Access Required?” on page 97 
* “How SSH Access for eDirectory Users Works" on page 97 
+ "SSH Security Considerations" on page 98 


When Is SSH Access Required? 


SSH access is required for the following: 


* SSH administration access for eDirectory users: For eDirectory users to manage the server 
through an SSH connection, they must have SSH access as LUM-enabled users (eDirectory 
users configured for access to Linux services). 


NOTE: The standard Linux root user is a local user, not an eDirectory user. The root user 


always has SSH access as long as the firewall allows it. 





* Access to NSS Volume Management in NetStorage: When an OES 2 Linux server has NSS 
volumes, eDirectory contains an object named nssvolumes that provides management access to 
the volumes through the File Access (NetStorage) iManager plug-in. Using the plug-in to 
manage NSS volumes, assign trustee rights, salvage and purge files, etc. requires SSH access to 
the server. 


Although eDirectory administrators can create Storage Location Objects to the NSS volumes 
without SSH access, providing that they know the path to the volume on the POSIX file system 
and other volume information, having SSH access makes administering NSS volumes in 
NetStorage much easier. 


* Access to any NetStorage Storage Location Objects based on SSH: The NetStorage server 
provides Web access to directories and files on other servers (or on itself). 


Typically, either an NCP or a CIFS connection is used for connecting the NetStorage server 
with storage targets. However, an SSH connection can also be used, and if it is, the users 
accessing data through the connection must have SSH access to the data on the target servers. 


How SSH Access for eDirectory Users Works 
For eDirectory users, the following work together to control SSH access: 


* Firewall: As mentioned, the default firewall configuration on an OES 2 Linux server doesn't 
allow SSH connections with the server. This restricts the root user as well. Therefore, the first 
requirement for SSH access 1s configuring the firewall to allow SSH services. 


* Linux User Management (LUM) must allow SSH as a service: In OES 2 Linux, access to 
SSH and other Linux services is controlled through Linux User Management (LUM), and each 
service must be explicitly included in the LUM configuration on each server. 


* LUM-enabling: After SSH is included as a LUM-enabled service on a server, at least one 
group and its users must be enabled for LUM. Only LUM-enabled eDirectory users can have 
SSH access. 


* AlleDirectory Groups must allow access: SSH access is inherited from the LUM-enabled 
groups that a user belongs to, and access is only granted when all of the groups to which a user 
belongs allow it. 
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* The Samba connection: Users who are enabled for Samba (CIFS) file services are added by 
default to an OES-created Samba group that: 


* Is LUM-enabled. 
* Doesn't specify SSH as an allowed service. 


Therefore, because SSH access requires that all of a user's groups must all allow access, Samba 
users are denied SSH access unless 


* The user is removed from the Samba group. 
Or 


* The Samba group is modified to allow SSH access for all Samba users. 


SSH Security Considerations 


Remember that SSH access lets users browse and view most directories and files on a Linux server. 
Even though users might be prevented from modifying settings or effecting other changes, there are 
serious security and confidentiality issues to consider before granting SSH access to anyone. 


11.4.2 Setting Up SSH Access for LUM-enabled eDirectory 
Users 


If you need to grant SSH access to an eDirectory user, complete the instructions in the following 
sections in order, as they apply to your situation. 

* "Allowing SSH Access Through the Firewall" on page 98 

* "Adding SSH as an Allowed Service in LUM" on page 98 

* "Enabling Users for LUM" on page 99 

* "Restricting SSH Access to Only Certain LUM-Enabled Users" on page 99 

* "Providing SSH Access for Samba Users" on page 100 


Allowing SSH Access Through the Firewall 
1 On the OES 2 Linux server you are granting access to, open the YaST Control Center and click 
Security and Users > Firewall. 
2 In the left navigation frame, click Allowed Services. 
3 Inthe A/lowed Services drop-down list, select SSH. 
4 Click Add > Next > Accept. 


The firewall is now configured to allow SSH connections with the server. 


Adding SSH as an Allowed Service in LUM 


1 If SSH is already an allowed service for Linux User Management on the server, skip to 
"Enabling Users for LUM" on page 99. 
or 


If SSH is not an allowed service for Linux User Management on the server, continue with 
Step 2. 


2 On the OES 2 Linux server, open the YaST Control Center; then, in the Open Enterprise Server 
group, click OES Install and Configuration. 
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3 Click Accept. 


4 When the Novell Open Enterprise Server Configuration screen has loaded, click the Disabled 
link under Linux User Management. 


The option changes to Enabled and the configuration settings appear. 

Click Linux User Management. 

Type the eDirectory Admin password in the appropriate field, then click OK > Next. 
In the list of allowed services, click sshd. 

Click Next > Next > Finish. 


Each LUM-enabled group in eDirectory, except the system-created Samba group, now shows 
SSH as an allowed service. The Samba group shows the service as not allowed (or literally 
speaking, sshd is not checked). 


on OOM 


Enabling Users for LUM 
There are numerous ways to enable users for LUM. 


For example, in iManager > Linux User Management there are options for enabling users (and 
choosing a Group in the process) or enabling groups (and enabling users in the process). Linux 
enabling is part of the process required for Samba access. And finally, there are also command line 
options. 


For specific instructions, refer to “Managing User and Group Objects in eDirectory” in the OES 2 
SP2: Novell Linux User Management Technology Guide. 


After you configure the server's firewall to allow SSH, add SSH as an allowed service, and LUM- 
enable the eDirectory users you want to have SSH access, if those same users are not also enabled 
for Samba on the server, they now have SSH access to the server. 


On the other hand, if you have installed Samba on the server, or if you install Samba in the future, 
the users who are configured for Samba access will have SSH access disabled. 


To restore access for users impacted by Samba, see "Providing SSH Access for Samba Users" on 
page 100. 


Of course, many network administrators limit SSH access to only those who have administrative 
responsibilities. They don't want every LUM-enabled user to have SSH access to the server. 


If you need to limit SSH access to only certain LUM-enabled users, continue with “Restricting SSH 


Access to Only Certain LUM-Enabled Users" on page 99. 


Restricting SSH Access to Only Certain LUM-Enabled Users 


SSH Access is easily restricted for one or more users by making them members of a LUM-enabled 
group and then disabling SSH access for that group. All other groups assignments that enable SSH 
access are then overridden. 
1 Open iManager in a browser using its access URL: 
httpz/IP AddresshiManager.html 
where JP Address is the IP address of an OES 2 server with iManager 2.7 installed. 
2 Inthe Roles and Tasks list, click Groups > Create Group. 
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Type a group name, for example NoSSHGroup, and select a context, such as the container 
where your other Group and User objects are located. Then click OK. 


In the Roles and Tasks list, click Directory Administration > Modify Object. 
Browse to the group you just created and click OK. 

Click the Linux Profile tab. 

Select the Enable Linux Profile option. 


In the Add UNIX Workstation dialog box, browse to and select the UNIX Workstation objects 
for the servers you are restricting SSH access to, then click OK > OK. 


Click Apply > OK. 
In the Roles and Tasks list, click Modify Object, browse to the group again, then click OK. 
Click the Other sub-tab. 


In the Unvalued Attributes list, select uamPosixPAMServiceExcludeList, then click the 
left-arrow to move the attribute to the Valued Attributes list. 


In the Add Attribute dialog box, click the plus sign (+) next to the empty drop-down list. 
In the Add item field, type sshd, then click OK > OK. 

Click the Members tab. 

Browse to and select the User objects that shouldn’t have SSH access, then click OK. 
Click Apply > OK. 


Providing SSH Access for Samba Users 


There are two options for providing SSH access to users who have been enabled for Samba access: 


* 


You can remove the user from the server name-W-SambaUserGroup. 





IMPORTANT: This presupposes that the user is a member of a different LUM-enabled group 
that also provides access to the server. If the user was enabled for LUM only as part of a Samba 
configuration, then removing the user from the Samba group breaks access to Samba and the 
user does not have SSH access. 


You can change access for the entire Samba group by moving the 
uamPosicPAMServiceExcludeList attribute from the Valued Attributes list to the Unvalued 
Attributes list, using the instructions in “Restricting SSH Access to Only Certain LUM-Enabled 
Users" on page 99 as a general guide. 





NOTE: Although the option to disable SSH access through the Modify Group iManager plug- 
in is much more simple and straightforward, that option is not working as of this writing. 
Although the plug-in appears to deselect sshd as an allowed service, the service is still selected 
when group information is reloaded. Novell plans to address this issue in the near future. 
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Network Services 


Network services as used in this section, are associated with protocols that provide the following: 


* Data packet transport on the network. 
* Management of IP addresses and DNS names. 


* Time synchronization to make sure that all network devices and eDirectory™ replicas and 
partitions have the same time. 


* Discovery of network devices and services, such as eDirectory, printers, and so on as required 
by certain applications, clients, and other services. 


This section discusses the following: 


* Section 12.1, “TCP/IP,” on page 101 

* Section 12.2, “DNS and DHCP,” on page 102 

* Section 12.3, "Time Services," on page 104 

* Section 12.4, “Discovery Services (SLP, WinSock, Etc.)," on page 115 
* Section 12.5, “SLP,” on page 116 


For links to more information and tasks, see the “Network Protocols" page in the OES 2 online 
documentation. 


12.1 TCP/IP 


Network nodes must support a common protocol in order to exchange packets. Transport protocols 
establish point-to-point connections so that nodes can send messages to each other and have the 
packets arrive intact and in the correct order. The transport protocol also specifies how nodes are 
identified with unique network addresses and how packets are routed to the intended receiver. 


Open Enterprise Server 2 includes the Novell® TCP/IP stack on NetWare? and standard Linux TCP/ 
IP support on SUSE® Linux Enterprise Server 10. Both comply with the latest RFCs. 


12.1.1 Coexistence and Migration Issues 


Internetwork Packet Exchange™ (IPX™) was the foundational protocol for NetWare from the 1980s 
until the release of NetWare 5.0, when support for pure TCP/IP became standard. 


Coexistence between IPX and TCP/IP networks is still supported on NetWare, but IPX is not 
supported on Linux. 


Data migration from TCP/IP to IPX is possible. IPX compatibility must be maintained on both the 
source and destination servers. Applications and services that run only on IPX must be either 
rewritten or replaced. After all IPX dependencies are resolved, you can safely remove IPX support 
from your NetWare servers. 


For more information on deploying TCP/IP in a NetWare environment, see the NW 6.5 SP8: TCP/ 
IP Administration Guide. 
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12.2 DNS and DHCP 


Domain Name Service (DNS) is the standard naming service in TCP/IP-based networks. It converts 
IP addresses, such as 192.168.1.1, to human-readable domain names, such as 
myserver.example.com, and it reverses the conversion process as required. 


The Dynamic Host Configuration Protocol (DHCP) assigns IP addresses and configuration 
parameters to hosts and network devices. 


For NetWare, Novell developed directory-integrated DNS/DHCP services that leverage eDirectory 
to provide centralized configuration and management through a Java* console accessible in 


iManager. 


OES 2 Linux includes a ported version of the NetWare DNS service, and eDirectory integration with 
ISC DHCP as explained in the sections that follow. 


¢ Section 12.2.1, “DNS Differences Between NetWare and OES 2 Linux,” on page 102 
¢ Section 12.2.2, “DHCP Differences Between NetWare and OES 2 Linux,” on page 103 


12.2.1 DNS Differences Between NetWare and OES 2 Linux 


The following are differences between DNS on NetWare and OES 2 Linux: 


Table 12-1 DNS: OES 2 NetWare vs. OES 2 Linux 








Feature or Command OES 2 NetWare OES 2 Linux 
Auditing Yes No 
DNSMaint Yes No 

Fault Tolerance Yes Yes 





Filenames and paths: 





* Server binary 


sys:/system/named.nlm 


* 


/opt/novell/named/bin/ 
novell-named 





* .db, .jn1 file 


sys:/etc/dns 


/etc/opt/novell/named/ 
named.conf 





* Stat file, info file 


/var/opt/novell/log/ 
named/named.run 





Console commands: 





* Start the server 


named 


rcnovell-named or novell- 
named 





* Stop the server 


named stop 


rcnovell-named stop 





* Check Status 


named status 
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rcnovell-named status 


Feature or Command OES 2 NetWare 


OES 2 Linux 





* Unsupported * N/A + [-dc categories] 
command + [-mstats] 
parameters 
* [-nno of cpus] 
* [-qstats] 
Journal log size Specify at the command prompt by Specify by using the iManager plug-in 


using the jsize argument. 


> max-journal-size field. 





Management iManager 
Command Line Interface 


iManager 
Command Line Interface 


Unlike the Netware implementation, 
command line parameters cannot be 
passed when loading and unloading. 





SNMP Support Yes 


No 


12.2.2 DHCP Differences Between NetWare and OES 2 Linux 


Table 12-2 DHCP: OES 2 NetWare vs. OES 2 Linux 


Feature or Command OES 2 NetWare 


Auditing Yes 


OES 2 Linux 


No 





Filenames and paths: 











* Conf file * N/A * /etc/dhcpd.conf 

* Leases * Stored in eDirectory * /var/lib/dhcp/db/ 
dhcpd.leases 

* Logfile * sys:/etc/dhcp/ * /var/log/dhcpd.log 


dhcpsrvr.log 





* Startup log * N/A 


* /var/log/dhcp-ldap- 
startup.log 


This is a dump of DHCP 
configurations read from 
eDirectory when the DHCP 
server starts. 





Management iManager 2.7 (Wizard-based) 


iManager 2.7 (Tab-based) 


Unlike the NetWare implementation, 
command line parameters cannot be 
passed when loading and unloading. 





Migration N/A 


There is seamless migration support 
from NetWare. 





Schema changes N/A 


There are separate locator and group 
objects for centralized management 
and easy rights management. 
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Feature or Command OES 2 NetWare OES 2 Linux 


SNMP Support Yes No 





Subnet naming Yes No 


12.3 Time Services 


The information in this section can help you understand your time services options and set up time 
synchronization on your OES 2 servers: 
* Section 12.3.1, “Overview of Time Synchronization,” on page 104 
* Section 12.3.2, “Planning for Time Synchronization,” on page 108 
* Section 12.3.3, “Coexistence and Migration of Time Synchronization Services,” on page 111 
* Section 12.3.4, “Implementing Time Synchronization,” on page 113 
* Section 12.3.5, “Configuring and Administering Time Synchronization,” on page 114 


* Section 12.3.6, “Daylight Saving Time,” on page 115 


12.3.1 Overview of Time Synchronization 


All servers in an eDirectory tree must have their times synchronized to ensure that updates and 
changes to eDirectory objects occur in the proper order. 


eDirectory gets its time from the server operating system (NetWare or Linux) of the OES 2 server 
where it is installed. It is, therefore, critical that every server in the tree has the same time. 


* “Understanding Time Synchronization Modules” on page 104 


* “OES 2 Servers as Time Providers" on page 106 


* “OES 2 Servers as Time Consumers" on page 107 


Understanding Time Synchronization Modules 


Because your OES eDirectory tree might contain servers running OES 2 Linux, OES 2 NetWare, or 
previous versions of NetWare, you must understand the differences in the time synchronization 
modules that each operating system uses and how these modules can interact with each other. 


* “OES 2 Linux vs. OES 2 NetWare” on page 104 
* “OES 2 Servers Use the Network Time Protocol (NTP) to Communicate" on page 105 
* "Compatibility with Earlier Versions of NetWare" on page 105 


OES 2 Linux vs. OES 2 NetWare 


As illustrated in Figure 12-1, OES 2 NetWare (NetWare 6.5) can use either the Network Time 
Protocol (NTP) or Timesync modules for time synchronization. Both modules can communicate 
with OES 2 Linux by using NTP. However, when installing virtualized NetWare, Timesync should 
always be used (see Section 6.12.3, “Always Use Timesync Rather Than NTP,” on page 67). 


OES 2 Linux must use the NTP daemon (xntpd). 


104 NW 6.5 SP8: Planning and Implementation Guide 


Figure 12-1 Time Synchronization for Linux and NetWare 





only or 
Ht E ms 
OES Linux OES NetWare 
and 
NetWare 6.5 


OES 2 Servers Use the Network Time Protocol (NTP) to Communicate 


Because OES 2 Linux and NetWare servers must communicate with each other for time 
synchronization, and because Linux uses only NTP for time synchronization, it follows that both 
Linux and NetWare must communicate time synchronization information by using NTP time 
packets. 


However, this doesn't limit your options on NetWare. 


Figure 12-2 illustrates that OES 2 Linux and NetWare servers can freely interchange time 
synchronization information because OES 2 NetWare includes the following: 


* A TIMESYNC NLM™ that both consumes and provides NTP time packets in addition to 
Timesync packets. 


* An XNTPD NLM that can provide Timesync packets in addition to offering standard NTP 
functionality. 





NOTE: Although NetWare includes two time synchronization modules, only one can be loaded at a 
time. 





Figure 12-2 NTP Packet Compatibilities with All OES Time Synchronization Modules 


NTP packets 


ih 


Timesync packets 


| 











XNTPD NLM 


TIMESYNC NLM 
OES Linux | | 


Compatibility with Earlier Versions of NetWare 


xntpd daemon 


OES NetWare 
and 
| NetWare 6.5 | 





: 


Earlier versions of NetWare (version 4.2 through version 6.0) do not include an NTP time module. 
Their time synchronization options are, therefore, more limited. 


NetWare 5.1 and 6.0 Servers 


Figure 12-3 illustrates that although NetWare 5.1 and 6.0 do not include an NTP time module, they 
can consume and deliver NTP time packets. 
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Figure 12-3 NTP Compatibility of NetWare 5.1 and 6.0 
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Figure 12-4 illustrates that NetWare 4.2 and 5.0 servers can only consume and provide Timesync 
packets. 


Figure 12-4 Synchronizing Time on NetWare 5.0 and 4.2 Servers 
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Therefore, if you have NetWare 4.2 or 5.0 servers in your eDirectory tree, and you want to install an 
OES 2 Linux server, you must have at least one NetWare 5.1 or later server to provide a “bridge” 
between NTP and Timesync time packets. Figure 12-5 on page 107 illustrates that these earlier 
server versions can synchronize through an OES 2 NetWare server. 





IMPORTANT: As shown in Figure 12-4, we recommend that NetWare 4.2 servers not be used as a 
time source. 





OES 2 Servers as Time Providers 


Figure 12-5 shows how OES 2 servers can function as time providers to other OES 2 servers and to 
NetWare servers, including NetWare 4.2 and later. 
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Figure 12-5 OES 2 Servers as Time Providers 
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OES 2 Servers as Time Consumers 


Figure 12-6 shows the time sources that OES 2 servers can use for synchronizing server time. 


IMPORTANT: Notice that NetWare 4.2 is not shown as a valid time source. 





Figure 12-6 OES 2 servers as Time Consumers 
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12.3.2 Planning for Time Synchronization 


Use the information in this section to understand the basics of time synchronization planning. 


* “NetWork Size Determines the Level of Planning Required” on page 108 
* “Choosing between Timesync and NTP (NetWare Only)" on page 109 
* "Planning a Time Synchronization Hierarchy before Installing OES” on page 110 


For more detailed planning information, refer to the following resources: 


* "How Timesync Works" in the NW 6.5 SP8: Network Time Synchronization Administration 
Guide 


* "Network Time Protocol" in the NW 6.5 SP8: NTP Administration Guide 
* NTP information on the Web (http://www.cis.udel.edu/~mills/ntp.html) 


NetWork Size Determines the Level of Planning Required 


The level of time synchronization planning required for your network is largely dictated by how 
many servers you have and where they are located, as explained in the following sections. 

* "Time Synchronization for Trees with Fewer Than Thirty Servers" on page 108 

* "Time Synchronization for Trees with More Than Thirty Servers" on page 108 


* “Time Synchronization across Geographical Boundaries" on page 109 


Time Synchronization for Trees with Fewer Than Thirty Servers 


If your tree will have fewer than thirty servers, the default installation settings for time 
synchronization should be sufficient for all of the servers except the first server installed in the tree. 


You should configure the first server in the tree to obtain time from one or more time sources that are 
external to the tree. (See Step 1 in "Planning a Time Synchronization Hierarchy before Installing 
OES” on page 110.) 


All other servers (both Linux and NetWare) automatically point to the first server in the tree for their 
time synchronization needs. 


Time Synchronization for Trees with More Than Thirty Servers 


If your tree will have more than thirty servers, you need to plan and configure your servers with time 
synchronization roles that match your network architecture and time synchronization strategy. 
Example roles might include the following: 


* Servers that receive time from external time sources and send packets to other servers further 
down in the hierarchy 

* Servers that communicate with other servers in peer-to-peer relationships to ensure that they 
are synchronized 


Basic planning steps are summarized in Planning a Time Synchronization Hierarchy before 
Installing OES" on page 110. 
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Refer to the following sources for additional help in planning time server roles: 
* "Configuring Timesync on Servers” in the NW 6.5 SP8: Network Time Synchronization 
Administration Guide 
* “Modes of Time Synchronization” in the NW 6.5 SP8: NTP Administration Guide 
+ NTP information on the Web (http://www.cis.udel.edu/~mills/ntp. html) 


Time Synchronization across Geographical Boundaries 


If the servers in the tree will reside at multiple geographic sites, you need to plan how to synchronize 
time for the entire network while minimizing network traffic. For more information, see “Wide Area 
Configuration" in the NW 6.5 SP8: NTP Administration Guide. 


Choosing between Timesync and NTP (NetWare Only) 


When you install an OES 2 NetWare server, you can choose between Timesync and NTP for time 
synchronization. 


If you select the Timesync option, you can fully configure each server as you install it to match your 
time synchronization plan. 


If you choose the XNTPD option, you can designate up to three NTP time sources, but fine-tuning 
your NTP hierarchy requires some manual configuration after the installation is complete. For help, 
consult the NW 6.5 SP8: NTP Administration Guide. 


About Timesync 


Timesync is the Novell legacy time synchronization protocol first delivered with NetWare 4. Over 
the years it has evolved and is now capable of both consuming and delivering NTP packets and 
Timesync packets. 


Timesync is installed and configured by default to ensure the smooth integration of earlier versions 
of NetWare. 





IMPORTANT: For virtualized NetWare servers, you should always use Timesync and configure it 
to communicate using NTP as instructed in “Creating a Response File” and “Setting the Server Time 
Zone and Time Synchronization Method” in the NW65 SP8: Installation Guide. 


About NTP 
NTP is the emerging choice for many network administrators because: 
* They feel it is easier to manage a single time synchronization protocol. 


For example, the same basic configuration file (ntp.conf) can be used on both Linux and 
NetWare. 


* NTP is a cross-platform industry standard available on multiple platforms. 


* The XNTPD NLM that runs on OES 2 NetWare provides Timesync packets for NetWare 
servers that can't consume NTP (NetWare 5.0 and 4.2), enabling them to coexist on an NTP 
time network. 
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Where to Specify Time Synchronization in the NetWare Install 


The dialog box that lets you choose between Timesync and NTP is available as an advanced option 
in the Time Zone panel during the NetWare installation. Choosing between Timesync and NTP is 
documented in “Setting the Server Time Zone and Time Synchronization Method” in the NW65 
SP8: Installation Guide. 


Planning a Time Synchronization Hierarchy before Installing OES 


The obvious goal for time synchronization is that all the network servers (and workstations, if 
desired) have the same time. This is best accomplished by planning a time synchronization hierarchy 
before installing the first OES 2 server, then configuring each server at install time so that you form 
a hierarchy similar to the one outlined in Figure 12-7. 

Figure 12-7 A Basic Time Synchronization Hierarchy 


External, reliable 
time sources 


As you plan your hierarchy, do the following: 
1 Identify at least two authoritative external NTP time sources for the top positions in your 
hierarchy. 


* If your network already has an NTP server hierarchy in place, identify the IP address of an 
appropriate time server. This might be internal to your network, but it should be external 
to the eDirectory tree and it should ultimately obtain time from a public NTP server. 


¢ If your network doesn’t currently employ time synchronization, refer to the list of public 
NTP servers published on the ntp.org Web site (http://ntp.isc.org/bin/view/Servers/ 
WebHome) and identify a time server you can use. 


2 Plan which servers will receive time from the external sources and plan to install these servers 
first. 


3 Map the position for each Linux server in your tree, including its time sources and the servers it 
will provide time for. 


4 Map the position for each NetWare server in your tree: 


4a Include the server’s time sources and the servers it will provide time for. 
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4b Decide whether to use Timesync or NTP for your servers. (See “Choosing between 
Timesync and NTP (NetWare Only)” on page 109.) 


4c If your network currently has only NetWare 4.2 or 5.0 servers, be sure to plan for their 
time synchronization needs by including at least one newer NetWare server in the tree and 
configuring the older servers to use the newer server as their time source. (See “NetWare 
5.0 and 4.2 Servers” on page 106.) 


5 Be sure that each server in the hierarchy is configured to receive time from at least two sources. 


6 (Conditional) If your network spans geographic locations, plan the connections for time-related 
traffic on the network and especially across WANs. 


For more information, see “Wide Area Configuration” in the NW 6.5 SP8: NTP Administration 
Guide. 


For more planning information, see the following documentation: 


* NW 6.5 SP8: Network Time Synchronization Administration Guide 
* NW 6.5 SP8: NTP Administration Guide 


* NTP information found on the OES 2 Linux server in /usr/share/doc/packages/xntp and on the 
Web (http://www.cis.udel.edu/~mills/ntp.html) 


12.3.3 Coexistence and Migration of Time Synchronization 
Services 
The time synchronization modules in OES have been designed to ensure that new OES 2 servers, 


running on either NetWare or Linux, can be introduced into an existing network environment 
without disrupting any of the products and services that are in place. 


Both the Linux and NetWare installs automate the time synchronization process where possible, as 
explained in Section 12.3.4, "Implementing Time Synchronization," on page 113. 


This section discusses the issues involved in the coexistence and migration of time synchronization 
in OES in the following sections: 


* "Coexistence" on page 111 
* "Migration" on page 112 
Coexistence 


This section provides information regarding the coexistence of the OES time synchronization 
modules with existing NetWare or Linux networks, and with previous versions of the TIMESYNC 
NLM. This information can help you confidently install new OES 2 servers into your current 
network. 

* "Compatibility" on page 111 


* "Coexistence Issues" on page 112 


Compatibility 


The following table summarizes the compatibility of OES time synchronization modules with other 
time synchronization modules and eDirectory. These compatibilities are illustrated in Figure 12-5 on 
page 107 and Figure 12-6 on page 107. 
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Table 12-3 Time Synchronization Compatibility 


Module Compatibility 
TIMESYNC NLM (NetWare) Can consume time from 


* All previous versions of Timesync. However, the NetWare 4.2 
TIMESYNC NLM should not be used as a time source. 


* Any TIMESYNC or NTP daemon. 
Can provide time to 


* All previous versions of Timesync. 
* Any TIMESYNC or NTP daemon. 


XNTPD NLM (NetWare) Can consume time from 
* Any NTP daemon. 
Can provide time to 


¢ All previous versions of Timesync. 
* Any NTP daemon. 


xntpd daemon (SLES 10) Can consume time from 
* Any NTP daemon. 
Can provide time to 
* Any NTP daemon. 
eDirectory eDirectory gets its time synchronization information from the host 
OS (Linux or NetWare), not from the time synchronization modules. 
Coexistence Issues 


If you have NetWare servers earlier than version 5.1, you need to install at least one later version 
NetWare server to bridge between the TIMESYNC NLM on the earlier server and any OES 2 Linux 
servers you have on your network. This is because the earlier versions of Timesync can’t consume 
or provide NTP time packets and the xntpd daemon on Linux can't provide or consume Timesync 
packets. 


Fortunately, the TIMESYNC NLM in NetWare 5.1 and later can both consume and provide 
Timesync packets. And the XNTPD NLM can provide Timesync packets when required. 


This is explained in “Compatibility with Earlier Versions of NetWare” on page 105. 


Migration 
Your migration path depends on the platform you are migrating data to. 


* NetWare to NetWare: Time synchronization configuration settings are all migrated by the 
NetWare Migration Wizard (both Timesync and XNTPD modules) because all associated 
modules and configuration files reside on sys: system. 
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* NetWare to Linux: The OES 2 SPI Migration Tool can migrate time synchronization services 
from NetWare to Linux. For more information, see “Migrating Timesync/NTP from NetWare 
to NTP on OES 2 Linux" in the OES 2 SP2: Migration Tool Administration Guide. 


12.3.4 Implementing Time Synchronization 


As you plan to implement your time synchronization hierarchy, you should know how the OES 2 
NetWare and OES 2 Linux product installations configure time synchronization on the network. 
Both installs look at whether you are creating a new tree or installing into an existing tree. 

* "New Tree" on page 113 


* "Existing Tree" on page 114 


New Tree 


By default, both the OES 2 Linux and the OES 2 NetWare installs configure the first server in the 
tree to use its internal (BIOS) clock as the authoritative time source for the tree. 


Because BIOS clocks can fail over time, you should always specify an external, reliable NTP time 
source for the first server in a tree. For help finding a reliable NTP time source, see the NTP Server 
Lists (http://ntp.isc.org/bin/view/Servers/WebHome) on the Web. 

* "OES 2 Linux" on page 113 

* "OES 2 NetWare" on page 113 


OES 2 Linux 


When you configure your eDirectory installation, the OES 2 Linux install prompts you for the IP 
address or DNS name of an NTP v3-compatible time server. 


If you are installing the first server in a new eDirectory tree, you have two choices: 


* You can enter the IP address or DNS name of an authoritative NTP time source 
(recommended). 


* Youcan leave the field displaying Local Time, so the server is configured to use its BIOS clock 
as the authoritative time source. 





IMPORTANT: We do not recommend this second option because BIOS clocks can fail over 
time, causing serious problems for eDirectory. 





OES 2 NetWare 


By default, the NetWare install automatically configures the TIMESYNC NLM to use the server's 
BIOS clock. As indicated earlier, this default behavior is not recommended for production networks. 
You should, therefore, manually configure time synchronization (either Timesync or NTP) while 
installing each NetWare server. 


Manual time synchronization configuration is accessed at install time from the Time Zone dialog 
box by clicking the Advanced button as outlined in “Choosing between Timesync and NTP 
(NetWare Only)" on page 109 and as fully explained in "Setting the Server Time Zone and Time 
Synchronization Method" in the NW65 SP8: Installation Guide. 
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Existing Tree 


When a server joins an existing eDirectory tree, both OES installations do approximately the same 
thing. 


+ “OES 2 Linux” on page 114 
* "OES 2 NetWare" on page 114 


OES 2 Linux 


If you are installing into an existing tree, the OES 2 Linux install proposes to use the IP address of 
the eDirectory server (either NetWare or Linux) as the NTP time source. This default should be 
sufficient unless one of the following is true: 


+ The server referenced is a NetWare 5.0 or earlier server, in which case you need to identify and 
specify the address of another server in the tree that 1s running either a later version of NetWare 
or OES 2 Linux. 


* You will have more than 30 servers in your tree, in which case you need to configure the server 
to fit in to your planned time synchronization hierarchy. For more information, see "Planning a 
Time Synchronization Hierarchy before Installing OES" on page 110. 


The OES 2 Linux install activates the xntp daemon and configures it to synchronize server time with 
the specified NTP time source. After the install finishes, you can configure the daemon to work with 
additional time sources to ensure fault tolerance. For more information, see “Changing Time 
Synchronization Settings on a SLES 10 Server" on page 115. 


OES 2 NetWare 


If you are installing into an existing tree, the OES 2 NetWare install first checks to see whether you 
manually configured either NTP or Timesync time synchronization sources while setting the server 
Time Zone (see “Setting the Server Time Zone and Time Synchronization Method" in the NW65 
SP8: Installation Guide). 


If you will have more than 30 servers in your tree, you should have developed a time 
synchronization plan (see “Planning a Time Synchronization Hierarchy before Installing OES” on 
page 110) and used the Time Zone panel to configure your server according to the plan. 


If you haven’t manually configured time synchronization sources for the server (for example, if your 
tree has fewer than 30 servers), the install automatically configures the Timesync NLM to point to 
the IP address of the server with a master replica of the tree’s [ROOT] partition. 


12.3.5 Configuring and Administering Time Synchronization 


As your network changes, you will probably need to adjust the time synchronization settings on 
your servers. 


* “Changing Time Synchronization Settings on a SLES 10 Server" on page 115 


* "Changing Time Synchronization Settings on a NetWare Server" on page 115 
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Changing Time Synchronization Settings on a SLES 10 Server 


This method works both in the GUI and at the command prompt and is the most reliable method for 
ensuring a successful NTP implementation. 


1 Launch YaST on your SLES 10 server by either navigating to the application on the desktop or 
typing yast at the command prompt. 

2 Click Network Services > NTP Client. 

3 Inthe NTP Client Configuration dialog box, click Complex Configuration. 

4 Modify the NTP time settings as your needs require. 


Changing Time Synchronization Settings on a NetWare Server 


Time synchronization settings and their modification possibilities are documented in the following 
administration guides: 


* Timesync: NW 6.5 SP8: Network Time Synchronization Administration Guide 
* NTP: NW 6.5 SP8: NTP Administration Guide 


12.3.6 Daylight Saving Time 


For information about daylight saving time (DST), see the DST Master TID on the Novell Support 
site (http://www.novell.com/support/php/ 
search.do?cmd-displayKC &docType-kc&externalId-3094409) 


12.4 Discovery Services (SLP, WinSock, Etc.) 


Various discovery mechanisms are usually available on an OES 2 network. 


* DNS/DHCP 

* Directory services 

* Local host configuration files 

* Service Location Protocol (SLP services) 

* WinSock (NetWare only) 

* Universal Description, Discovery, and Integration (UDDI) server 
Some systems are designed to leverage only a single discovery technology. Others choose among 
the various providers. And some use different technologies in combination with each other. 

* Section 12.4.1, “Novell SLP and OpenSLP,” on page 116 

* Section 12.4.2, “WinSock and Discovery (NetWare only),” on page 116 

* Section 12.4.3, “UDDI and Discovery,” on page 116 

* Section 12.4.4, *CIMOM and Discovery," on page 116 
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12.4.1 Novell SLP and OpenSLP 


NetWare 3 and 4 used the IPX-based Service Advertising Protocol (SAP) as the discovery 
mechanism. All the servers advertised their services automatically. If a server went offline, the SAP 
information on the network was dynamically refreshed. 


Starting with NetWare 5 and pure TCP/IP, the Service Location Protocol was adopted as the default, 
though optional, discovery mechanism. SLP was chosen because it was the TCP/IP-based protocol 
most like SAP in its automatic nature and dynamic refresh capabilities. 


For more information, see Section 12.5, “SLP,” on page 116. 


12.4.2 WinSock and Discovery (NetWare only) 


WinSock collects service information from all available service-discovery sources. 


NetWare Loadable Module™ (NLM) programs that leverage WinSock have access to all discovery 
services on the network automatically. Therefore, if you removed SLP as a source of information 
(for example) and placed the information into DNS or a local host file, any NLM that leverages 
WinSock would not know the difference. 





NOTE: There is no WinSock equivalent in the Linux environment. BSDSock provides for transport 
only, not name resolution. Therefore, any NetWare services that leveraged WinSock and are 
provided on OES 2 Linux use other service-discovery mechanisms. 





12.4.3 UDDI and Discovery 


UDDI is an open source, platform-independent registry that lets you provide a discovery service on 
the World Wide Web to easily locate, integrate, and manage businesses and services. 


For NetWare 6.5, Novell developed a directory-enabled UDDI server for use with the exteNd™ 
J2EE™ Application Server. Starting with OES 1 NetWare, the UDDI server component was 
removed from the list of products that can be installed. 


However, the Novell UDDI server has been released as open source software and is available for 
download on the Novell Forge Web site (http://forge.novell.com/modules/xfmod/project/ 
showfiles.php?group id-1025). 


12.4.4 CIMOM and Discovery 


The current OpenWBEM implementation of the Common Information Model Object Manager 
(CIMOM) lists SLP as an optional discovery provider. If SLP is to be used with CIMOM, it must be 
in compliance with the SLP API specification (RFC 2614). The default discovery vehicle for 
CIMOM is the statically configured URI. For more information, see the CIMOM specification at the 
Desktop Management Task Force (DMTF) Web site (http://www.dmtf.org). 


12.5 SLP 


OES 2 includes separate but compatible SLP solutions on its Linux and NetWare platforms: 
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This section discusses the following topics: 


* Section 12.5.1, “Why SLP Is Needed,” on page 117 

* Section 12.5.2, “Comparing Each Platform’s SLP Solution,” on page 117 
* Section 12.5.3, “Setting Up OpenSLP on OES 2 Networks,” on page 118 
* Section 12.5.4, “Using Novell SLP on OES 2 Networks," on page 122 


12.5.1 Why SLP Is Needed 


OES 2 NetWare: Although many other applications and server types rely on SLP for service 
discovery, OES 2 services on NetWare are actually integrated with eDirectory, and if eDirectory is 
configured correctly, the services work without SLP. However, SLP is automatically provided on 
NetWare for other services that might be installed. 


OES 2 Linux: On the other hand, for OES 2 services to work on OES 2 Linux, the server must 
either: 


+ Have an eDirectory replica installed. 


This is not automatic after the third server installed in a tree, nor is having more than three to 
five replicas on servers in the tree recommended. 


* Have eDirectory registered with the OpenSLP service running on the server. 


This requires SLP configuration either during the OES 2 Linux installation or manually. 
12.5.2 Comparing Each Platform's SLP Solution 


Table 12-4 SLP Solutions 


Platform NetWare SLES 10 SP1 

SLP Solution Novell SLP OpenSLP 

About the The Novell version of SLP adapted OpenSLP is an implementation of various 

Solution portions of the SLP standard to provide a IETF specifications, including RFC 2614 
more robust service advertising (SLP version 2.0). It is the default SLP 
environment. service installed on SLES 10. 


Novell SLP remains the default discovery In OES 2 Linux, OpenSLP is available for 
mechanism for OES 2 NetWare servers. those applications that require it. The 


However, all NetWare service default discovery mechanism is actually 
components that engage in discovery, DNS, but SLP must be present for any 
including Novell Client™ software, can applications that require it, especially in 
use alternative mechanisms such as those cases where the OES 2 Linux server 
DNS, eDirectory, or local host is the fourth or later server added to a tree 
configuration files. and doesn't have an eDirectory replica 


automatically installed. 
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Platform 


Differences 


Compatibility 


Documentation 


NetWare 


Novell SLP directory agents (DAs) store 
service registrations for their SLP scope 
in eDirectory. 


As a new service registration is stored in 
eDirectory, other DAs assigned to the 
same scope are notified so that they can 
refresh their caches with the latest 
service information. 


Also, when a Novell SLP DA starts up, it 
immediately populates its cache with the 
latest service information stored in 
eDirectory. 





NOTE: Novell SLP DAs do not directly 
share information with each other as 
many administrators have assumed. But 
they do maintain well synchronized 
caches through eDirectory as described 
above. 





Novell SLP user agents (UAs) or service 
agents (SAs) can access both Novell 
SLP DAs and OpenSLP DAs. 


“Implementing the Service Location 
Protocol” in the Novell eDirectory 8.8 
Administration Guide. 


SLES 10 SP1 


OpenSLP directory agents (DAs) are 
completely separate and have no way to 
initially populate or refresh their service 
information the way Novell SLP DAs do. 


A DA's cache is empty when it starts up and 
is populated only as services register 
themselves. 


OpenSLP-based user agents or service 
agents can access both Novell SLP DAs 
and OpenSLP DAs. 


"Configuring OpenSLP for eDirectory” in 
the Novell eDirectory 8.8 Administration 
Guide. 


12.5.3 Setting Up OpenSLP on OES 2 Networks 


SLP services are always installed as part of both NetWare and SLES 10 SP1 (the underlying OES 2 
Linux platform). On NetWare the Novell SLP service is configured to automatically work with 
eDirectory and other services. On OES 2 Linux, the OpenSLP service must be manually configured 
to work with eDirectory and other services. 


* "When Is OpenSLP Required?" on page 118 


¢ "Setting Up an OpenSLP DA Server" on page 119 


* "Configuring OES 2 Linux Servers to Access the OpenSLP DA" on page 120 


* "Configuring NetWare Servers to Use the OpenSLP Service" on page 121 


When Is OpenSLP Required? 


You must set up OpenSLP on your OES 2 Linux server if both of the following apply: 


* You plan to install more than three servers into a new tree being created on an OES 2 Linux 


Server. 


* You either don't have an existing Novell SLP service, or you don't want to continue using 
Novell SLP. 
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IMPORTANT: If you need to set up OpenSLP for the reasons above, you should do it before you 
install the fourth OES 2 Linux or any NetWare servers in your tree. Setting up SLP services on every 
OES 2 Linux server is recommended. 





Setting Up an OpenSLP DA Server 


If you need OpenSLP and you don’t already have an OpenSLP Directory Agent (DA) set up on your 
network, for simplicity’s sake we recommend that you set up the first OES 2 Linux server in your 
tree as an OpenSLP DA. Although SLP services can be managed without having a Directory Agent, 
that approach is far less robust, requires multicasting, and for OES 2 Linux it involves disabling the 
firewall. 


After creating the DA, you can then configure all subsequently installed servers to either point to 
that DA or to other DAs you create later. 


1 On the OES 2 Linux server that will become the DA, open the /etc/slp.conf file in a text 
editor. 

2 Inslp.conf, remove the semicolon [;]) from the beginning of the following line: 
;net.slp.isDA - true 
so that it reads 
net.slp.isDA - true 

3 Find the following line: 


;net.slp.useScopes = myScopel, myScope2, myScope3 





IMPORTANT: The example in the configuration file is misleading because the spaces after 
each comma are not ignored as one might expect them to be. 


Therefore, the scope names created or configured by the statement after the first comma 
actually have leading spaces in them. For example, the first scope name is *myScopel" but the 
scope names that follow it all have leading spaces, * myScope2", * myScope3" and so on. This 
is a problem, especially if one of the later names becomes the first name in a subsequent SLP 
configuration and the leading space is 1gnored. 


If you use the scopes given in the example, remove the spaces between the entries. 





4 Modify the line by removing the semicolon and typing the name ofthe scope you want this DA 
to use to provide service information on the network. For example, you might change the line 
as follows: 


net.slp.useScopes = Directory 








IMPORTANT: Although SLP provides a default scope 1f no scope is specified, it is always 
good practice to define one or more scopes by configuring the net.slp.useScopes parameter in 
slp.conf. 


Scopes group and organize the services on your network into logical categories. For example, 
the services that the Accounting group needs might be grouped into an Accounting scope. 


More information about scope planning is available in *SLP Scopes " in the Novell eDirectory 
8.6 Administration Guide and on the OpenSLP Web site (http://www.openslp.org/). 


When no scope is specified, all services are registered in a scope named Default. 
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5 Configure the firewall on the DA server to allow SLP daemon traffic: 
5a In the YaST Control Center, click Security and Users > Firewall. 
5b In the left navigation frame, click Allowed Services. 
5c Click the Services to Allow drop-down list and select SLP Daemon. 
5d Click Add > Next. 
5e Click Accept. 
6 At the command prompt, enter the following command to restart the SLP daemon: 
rcslpd restart 


7 (Conditional) If you are doing this after installing OES 2 and eDirectory, you must also restart 
eDirectory by entering the following command: 


rcndsd restart 
8 Continue with the following sections that apply to your situation: 
* Configuring OES 2 Linux Servers to Access the OpenSLP DA (page 120) 
* Configuring NetWare Servers to Use the OpenSLP Service (page 121) 


Configuring OES 2 Linux Servers to Access the OpenSLP DA 


If you created the OpenSLP DA on an OES 2 Linux server installed in your tree, then SLP is 
properly configured on that server and these instructions do not apply to it. 


For all other OES 2 Linux servers installed in your eDirectory tree, you should complete one of the 
following procedures as it applies to your situation: 

* "Configuring for DA Access During the OES 2 Linux Installation" on page 120 

* "Configuring for DA Access Before or After Installing the OES 2 Linux Server" on page 121 


Configuring for DA Access During the OES 2 Linux Installation 


As you install OES 2 Linux by using the instructions in the *Novell eDirectory Services" section of 
the OES 2 SP2: Installation Guide, do the following: 


1 When you reach the SLP section of the installation, select Configure SLP to Use an Existing 
Directory Agent. 


The first option, Do not configure SLP, causes problems with eDirectory and other services if 
this 1s the fourth or later server installed in the tree. The second option, Use Multicast, requires 
that you disable the firewall on the server. Disabling the firewall is always discouraged. 


2 Inthe Service Location Protocol Scopes field, specify the scope you defined in Step 4 on 
page 119. You can also list additional scopes, separated by commas (no spaces). 


For example, you might type Directory in the field if that is the scope name you assigned to 
the DA you created. 


3 In the Configured SLP Directory Agent field, type the IP address of the DA server you defined 
in "Setting Up an OpenSLP DA Server" on page 119. You can also list additional DA 
addresses, separated by commas. 


4 Retum to the *Novell eDirectory Services" instructions in the OES 2 SP2: Installation Guide. 
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Configuring for DA Access Before or After Installing the OES 2 Linux Server 


Whether you configure DA access before installing OES 2 Linux on a SLES 10 SP1 server or after a 
simultaneous install of SLES 10 SP1 and OES 2, the manual DA configuration process is the same. 


1 Open /etc/slp.conf ina text editor. 
2 Find the following line: 


;net.slp.useScopes = myScopel, myScope2, myScope3 





IMPORTANT: The example in the configuration file is misleading because the spaces after 
each comma are not ignored as one might expect them to be. 


Therefore, the scope names created or configured by the statement after the first comma 
actually have leading spaces in them. For example, the first scope name is *myScopel" but the 
scope names that follow it all have leading spaces, * myScope2", * myScope3" and so on. This 
is a problem, especially if one of the later names becomes the first name in a subsequent SLP 
configuration and the leading space is ignored. 


If you use the scopes given in the example for some reason, remove the spaces between the 
entries. 





3 Modify the line by removing the semicolon and typing the name or names of the scopes you 
want this server to have access to. Be sure to include the scope you defined in Step 4 on 
page 119. 


For example, you might change the line as follows: 


net.slp.useScopes = Directory 





4 Find the following line: 
;net.slp.DAAddresses - myDal,myDa2,myDa3 


5 Modify the line by removing the semicolon and typing the actual IP address of the OpenSLP 
DA you defined in "Setting Up an OpenSLP DA Server" on page 119. 


net.slp.DAAddresses - IP Address 
6 Save the file and close it. 


7 Atthe Linux command prompt, enter the following to restart the SLP daemon and reset its 
configuration: 


rcslpd restart 


Configuring NetWare Servers to Use the OpenSLP Service 





IMPORTANT: NetWare uses Novell SLP by default and will configure a server for that service if 
possible. 





Complete one of the following as it applies to your situation: 


* "Configuring for DA Access During the NetWare Server Installation" on page 121 
* "Configuring for DA Access After Installing the NetWare Server" on page 122 


Configuring for DA Access During the NetWare Server Installation 


1 In the dialog box where you set up IP addresses for network boards, click Advanced. 
2 Click the SLP tab. 
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3 Specify the IP address of the OES 2 Linux DA servers—up to three. 


4 Type the list of scopes covered by the configured DAs that you want the NetWare server to 
have access to. 





IMPORTANT: We recommend you do not configure the server to use multicast because that 
necessitates disabling firewalls, which is never recommended. 





5 Click OK. 


Configuring for DA Access After Installing the NetWare Server 


1 Using a text editor, edit the SyS:ETC/slp.cfg file on the NetWare server and add the 
following line for each DA server you want the NetWare server to have access to: 





DA IPV4, IP Addressi 
DA IPV4, IP Address2 


where JP. AddressX is the IP address of an OES 2 Linux DA server. 
2 Save the file and close it. 


3 Atthe NetWare console prompt, specify the scopes you want the NetWare server to have access 
to, write the SLP cache to the registry, and restart the SLP service: 





set slp scope list = scopel,scope2,... 
flush cdbe 


set slp reset - on 
4 Verify that SLP is functioning correctly by entering the following command: 


display slp services 


12.5.4 Using Novell SLP on OES 2 Networks 


If you have a NetWare tree, you automatically have Novell SLP on your network and you can 
continue to use it as the SLP service for both OES 2 platforms. 


This section discusses the following: 


* “NetWare Is Configured with Novell SLP By Default" on page 122 
* "Configuring OES 2 Linux Servers to Access the Novell SLP DA" on page 123 
* "Checking the Status of Novell SLP Services" on page 124 


NetWare Is Configured with Novell SLP By Default 


When you install NetWare, if you don't specify an alternate SLP configuration, the server is 
automatically configured to use Novell SLP in a way that is sufficient for most networks. 
Information about Novell SLP and customization instructions is available in “Implementing the 
Service Location Protocol" in the Novell eDirectory 8.8 Administration Guide. 
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Configuring OES 2 Linux Servers to Access the Novell SLP DA 


For each of the OES 2 Linux servers installed in your eDirectory tree, you should complete one of 
the following procedures as it applies to your situation: 

* “Configuring for DA Access During the OES 2 Linux Installation" on page 123 

* “Configuring for DA Access Before or After Installing the OES 2 Linux Server" on page 123 


Configuring for DA Access During the OES 2 Linux Installation 


As you install OES 2 Linux, in the “Novell eDirectory Services" section of the OES 2 SP2: 
Installation Guide, do the following: 


1 When you reach the SLP section of the installation, select Configure SLP to Use an Existing 
Directory Agent. 


The first option, Do not configure SLP, causes problems with eDirectory and other services if 
this 1s the fourth or later server installed in the tree. The second option, Use Multicast, requires 
that you disable the firewall on the server. Disabling the firewall is always discouraged. 


2 Inthe Service Location Protocol Scopes field, specify one or more appropriate scopes that are 
defined on your network. 


If you aren't sure about the exact scope names, you can view the SLP configuration ofa 
NetWare server on the same network segment. Log into Novell Remote Manager on the server 
and click Manage Applications > SLP. 


You can list multiple scopes, separated by commas (no spaces). 
For example, you might type Directory in the field. 
3 In the Configured SLP Directory Agent field, type the IP address of an appropriate DA server. 


You can use Novell Remote Manager on a NetWare server if you aren't sure which address to 
use. 


You can also list additional DA addresses, separated by commas. 


4 Return to the “Novell eDirectory Services” instructions in the OES 2 SP2: Installation Guide. 


Configuring for DA Access Before or After Installing the OES 2 Linux Server 


Whether you configure DA access before installing OES 2 Linux on a SLES 10 SPI server or after a 
simultaneous install of SLES 10 SP1 and OES 2, the manual DA configuration process is the same. 
1 Open /etc/slp.conf in a text editor. 
2 Find the following line: 
;net.slp.useScopes = myScopel, myScope2, myScope3 





IMPORTANT: The example in the configuration file is misleading because the spaces after 
each comma are not ignored as one might expect them to be. 


Therefore, the scope names created or configured by the statement after the first comma 
actually have leading spaces in them. For example, the first scope name is *myScopel" but the 
scope names that follow it all have leading spaces, * myScope2”, * myScope3” and so on. This 
is a problem, especially if one of the later names becomes the first name in a subsequent SLP 
configuration and the leading space is ignored. 


If you use the scope names given in the example, remove the spaces between the entries. 
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Modify the line by removing the semicolon and typing the name or names of the scopes you 
want this server to have access to. 


If you aren’t sure about the exact scope names, you can view the SLP configuration of a 
NetWare server on the same network segment. Log into Novell Remote Manager on the server 
and click Manage Applications > SLP. 


You can list multiple scopes, separated by commas (no spaces). 


For example, you might change the line as follows: 





net.slp.useScopes = Directory 
Find the following line: 
;net.slp.DAAddresses = myDal,myDa2,myDa3 


Modify the line by removing the semicolon and typing the actual IP address of the Novell SLP 
DA (using Novell Remote Manager if necessary). 


net.slp.DAAddresses = IP Address 
Save the file and close it. 


At the Linux command prompt, enter the following to restart the SLP daemon and reset its 
configuration: 


rcslpd restart 


Enter the following commands to verify that the DA and scopes you configured are recognized. 


slptool findsrvs service: 
The DA server should be listed. 
slptool findscopes 

The scopes should be listed. 


If you did this after installing OES 2 Linux, enter the following name to verify that the tree is 
found: 


slptool findsrvs service:ndap.novell 


Checking the Status of Novell SLP Services 


There are several ways to check the status of Novell SLP services. 


* 


If you know the IP addresses of the DAs, check the SYS: \etc\slp.cfg file on non-DA 
servers to see if the DA IP addresses are listed. 





Gl 
= 


If you know the scope names, check for the proper scope name configuration by using the s] 
SLP SCOPE LIST command. 








Use the DISPLAY SLP SERVICES command to list all of the services that are registered in all of 
the scopes that the server is configured to use. 











Use iManager to open the scope container object to see all of the registered services. 


If you are registering different services in different scopes, look in the SYS:\etc\slp.cfg file 
for REGISTER TYPE lines. 

















At the DOS prompt on a Windows workstation with Client32™ installed, use the SLPINFO / 
ALL command. 
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Storage and File Systems 


Hosting shared data storage is one of the primary functions of network servers. Whether data 
volumes are directly attached to the server in RAID configurations or externally accessible in 
Storage Area Network (SAN) or Network Attached Storage (NAS) configurations, users need to be 
able to access their data on a continual basis. 


Use this section to understand the file storage solutions available in Open Enterprise Server 2 and 
then to plan a storage solution that meets your file system management needs. 


The “Storage and File Systems” section in the OES 2 online documentation provides overview, 
planning, implementation, and configuration links. 


This section provides the following information about the process of planning and implementing 
storage services in OES: 


* Section 13.1, “Overview of OES 2 Storage,” on page 125 

* Section 13.2, “Planning OES File Storage,” on page 130 

* Section 13.3, “Coexistence and Migration of Storage Services,” on page 137 
* Section 13.4, “Initial Setup Is Required for NetWare,” on page 139 

* Section 13.5, "Configuring and Maintaining Storage," on page 139 


Other storage-related topics in this guide: 
* Chapter 16, *Access Control and Authentication," on page 169 
* Section 16.2, "Authentication Services," on page 182 


* Appendix D, “Backup Services,” on page 251 
* Chapter 17, *File Services," on page 187 


13.1 Overview of OES 2 Storage 


This section presents the following overview information for the file systems included in OES: 
* Section 13.1.1, “Databases,” on page 125 
* Section 13.1.2, “iSCSI,” on page 126 
* Section 13.1.3, *File System Support in OES," on page 126 
* Section 13.1.4, “Storage Basics by Platform," on page 128 
* Section 13.1.5, “Storage Options,” on page 128 


* Section 13.1.6, *NetWare Core Protocol Support (Novell Client Support) on Linux," on 
page 130 


13.1.1 Databases 


See the topics in “databases” in the OES online documentation. 
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13.1.2 iSCSI 


See the topics in “iSCSI for NetWare” in the OES online documentation. 


13.1.3 File System Support in OES 


As shown in Figure 13-1, both OES 2 server platforms support Novell® Storage Services™ as well 
as their traditional file systems. 


Figure 13-1 File System Choices on OES 2 Servers 


SET Linux OES Ean 





Linux Traditional Novell Storage Services NetWare Traditional Novell Storage Services 
(NSS) (NSS) 

- Ext3 

- Reiser FS 

- XFS 


Table 13-1 summarizes OES file system types and provides links to more information. 
Table 13-1 File Systems Available on OES 2 Servers 


File System Type Summary Link for More Information 


Linux POSIX File Systems SLES 10 includes a number of For an overview of the supported 
different file systems, the most file systems in OES 2, see “File 
common of which are Ext3 and Systems Overview” in the NW 6.5 
ReiserFS. SP8: File Systems Management 


Guide. 
OES 2 services are supported on 


Ext3, ReiserFS, and XFS. 





NetWare? Traditional File System Although it is considered alegacy For more information, see the 
file system on NetWare servers, NW6.5 SP8: Traditional File 
the NetWare Traditional file System Administration Guide. 
system is still robust. It supports 
the NetWare file service access 
model. 
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File System Type Summary Link for More Information 


Novell Storage Services (NSS) NSS lets you manage your For an overview of NSS, see 
shared file storage for any size “Overview of NSS” in the NW 6.5 
organization. SP8: NSS File System 


Administration Guide. 
On Netware, NSS features 


include visibility, a trustee access 
control model, multiple 
simultaneous name space 
support, native Unicode, user and 
directory quotas, rich file 
attributes, multiple data stream 
support, event file lists, and a file 
salvage subsystem. 


Most of these features are also 
supported on NSS on Linux. For 
a feature comparison, see 
"Comparison of NSS on NetWare 
and NSS on Linux’ in the NW 6.5 
SP8: NSS File System 
Administration Guide. 


Novell Storage Services (NSS) 


The following sections summarize key points regarding NSS: 


* "Understanding NSS Nomenclature" on page 127 
* "Comparing NSS with Other File Systems" on page 127 
* “NSS and Storage Devices" on page 128 


Understanding NSS Nomenclature 


NSS uses a specific nomenclature to describe key media objects. These terms appear in both the 
NSS documentation and in NSS error messages. 


For more information, see “NSS Nomenclature" in the NW 6.5 SP8: NSS File System Administration 
Guide. 


Comparing NSS with Other File Systems 


Because OES 2 supports a variety of file systems, you might want to compare their features and 
benefits as outlined in the following sections of the NW 6.5 SP8: NSS File System Administration 
Guide: 

* NSS Linux vs. NSS NetWare: “Comparison of NSS on NetWare and NSS on Linux” 


* NSS Linux vs. Linux POSIX: “Comparison of NSS on Linux and NCP Volumes on Linux 
POSIX File Systems” 


* NSS Netware vs. NetWare Traditional: “Comparison of NSS on NetWare and the NetWare 
Traditional File System” 
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NSS and Storage Devices 


NSS supports both physical devices (such as hard disks) and virtual devices (such as software 
RAIDs and iSCSI devices). 


For more information on the various devices that NSS supports, see “Managing Devices” in the NW 


6.5 SP8: NSS File System Administration Guide. 


13.1.4 Storage Basics by Platform 


The following sections summarize storage basics for Linux and NetWare. 
* "Linux and File Systems” on page 128 
* "NetWare Directories" on page 128 
* "NetWare Storage Devices" on page 128 

Linux and File Systems 


For a high-level overview of the file system on Linux, including the root (/) directory, mount points, 
standard folders, and case sensitivity, see “Understanding Directory Structures in Linux POSIX File 
Systems" in the NW 6.5 SP8: File Systems Management Guide. 


NetWare Directories 


NetWare uses volumes and directories (or folders) to organize data. NetWare file systems support 
directory paths, fake root directories, Directory Map objects, and drive mappings. 


For more information, see “Understanding Directory Structures for the NSS and NetWare 
Traditional File Systems" in the NW 6.5 SP8: File Systems Management Guide. 


NetWare Storage Devices 


NetWare lets you use many different kinds of storage devices, including server disks, single storage 
devices, arrays of storage devices, and virtual storage devices. 


To understand how NetWare connects with and uses storage devices, see “Overview of Server Disks 


and Storage Devices for NetWare” in the NW6.5 SP8: Server Disks and Storage Devices. 


13.1.5 Storage Options 


The following sections summarize OES storage options. 


* “Dynamic Storage Technology” on page 128 
* "Direct-Attached Storage Options (NSS and Traditional)" on page 129 
* "Advanced Storage Options (NSS Only)" on page 129 


Dynamic Storage Technology 


Dynamic Storage Technology for OES 2 Linux lets you present the files and subdirectories on two 
separate NSS volumes as though they were on a single, unified NSS volume called a shadow 
volume. 
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NCP™ client users and Samba/CIFS users who access the primary volume see the files and 
subdirectories from both volumes as if they were all on one volume. All the actions they take— 
renaming, deleting, moving, etc.—are synchronized by Dynamic Storage Technology across the two 
volumes. 


Unlike the NCP client, backup tools see the volumes separately and can therefore apply one backup 
policy to the primary and a different backup policy to the secondary volume. 


You can use Dynamic Storage Technology to substantially reduce storage costs by placing your less 
frequently accessed files on less expensive storage media. You can even employ a “move on 
demand" migration strategy by defining new, more expensive SAN or RAID storage that is initially 
empty as the primary volume, and then configuring Dynamic Storage Technology so that data is 
migrated to this primary storage only when it is accessed. 


In addition, Dynamic Storage Technology doesn't suffer the performance penalty that HSM 
solutions do. 


For more information about Dynamic Storage Technology, see the OES 2 SP2: Dynamic Storage 
Technology Administration Guide. 


Direct-Attached Storage Options (NSS and Traditional) 


As shown in Figure 13-1 on page 126, you can install traditional volumes and Novell Storage 
System (NSS) volumes on both OES platforms. These devices can be installed within the server or 
attached directly to the server through an external SCSI bus. 


For more information, see “Direct Attached Storage Solutions” in the NW 6.5 SP8: Storage and File 
Services Overview. 


Advanced Storage Options (NSS Only) 


NSS volumes support the following advanced storage solutions, as documented in the NW 6.5 SP8: 
Storage and File Services Overview. 


* Network Attached Storage Solutions 


A dedicated data server or appliance that provides centralized storage access for users and 
application servers through the existing network infrastructure and by using traditional LAN 
protocols such as Ethernet and TCP/IP. When Gigabit Ethernet is used, access speeds are 
similar to direct attached storage device speeds. 
The disadvantage is that data requests and data compete for network bandwidth. 

* Storage Area Network Solutions 


A separate, dedicated data network consisting of servers and storage media that are connected 
through high-speed interconnects, such as Fibre Channel. 


* Novell iSCSI 


You can create a SAN using Novell iSCSI, which uses Novell eDirectory™ to manage 
iSCSI resources, including granting trustee rights and user file access. For information, 
see NW 6.5 SP8: iSCSI 1.1.3 Administration Guide. 


¢ Fault-Tolerant and High-Availability Architectures 
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Use one or more of the following technologies: 


* Multiple Path I/O: NSS helps prevent failure in the connection between the CPU and the 
storage device by automatically identifying multiple paths between each NetWare server 
and its storage devices. 


For more information, see “Managing Multipath I/O to Devices (NetWare)” in the NW 6.5 
SP8: NSS File System Administration Guide. 


* Software RAIDs: NSS supports software RAIDS to improve storage availability and 
performance by enhancing data fault tolerance and I/O performance. 


For more information, see “Managing NSS Software RAID Devices” in the NW 6.5 SP6: 
NSS File System Administration Guide. 


* Server Clusters: You can configure up to 32 NetWare servers or Linux servers into a high- 
availability cluster where resources and services are dynamically allocated to any server in 
the cluster and automatically switched to another server if the hosting server fails. 


By manually switching services, IT organizations can maintain and upgrade servers 
during production hours and eliminate scheduled downtime. 


For more information, see the NW6.5 SP8: Novell Cluster Services 1.8.5 Administration 
Guide and the OES 2 SP2: Novell Cluster Services 1.8.7 for Linux Administration Guide. 


13.1.6 NetWare Core Protocol Support (Novell Client Support) 
on Linux 


Many organizations rely on Novell Client™ software and the NetWare Core Protocol™ (NCP) for 
highly secure access to file storage services. 


Novell Storage Services (NSS) volumes are NCP volumes by nature, but you can also define Linux 
POSIX volumes as NCP volumes. The main difference in access control between NSS volumes and 
Linux POSIX volumes that are defined as NCP volumes is that NSS extended file and directory 
attributes are not available on Linux POSIX volumes. 


The NCP server for OES 2 Linux lets you attach to Linux POSIX volumes that are defined as NCP 
volumes using Novell Client software. For more information, see Section 17.6, “NCP 
Implementation and Maintenance," on page 210. 


13.2 Planning OES File Storage 


The following sections can help you plan for storage on your OES network: 


* Section 13.2.1, “Directory Structures," on page 130 

* Section 13.2.2, *File Service Support Considerations," on page 131 

* Section 13.2.3, *General Requirements for Data Storage," on page 131 

* Section 13.2.4, "OES 2 Linux Storage Planning Considerations," on page 131 
* Section 13.2.5, *NSS Planning Considerations," on page 136 


13.2.1 Directory Structures 


Linux: To plan the directory structures you need on OES 2 Linux, see “Understanding Directory 
Structures in Linux POSIX File Systems" in the NW 6.5 SP8: File Systems Management Guide. 
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Netware: To plan the directory structures you need on OES 2 NetWare, see “Planning Directory 
Structures for NetWare Servers" in the NW 6.5 SP8: File Systems Management Guide. 


13.2.2 File Service Support Considerations 


Figure 13-2 shows which file services can access which volume types. 


Figure 13-2 File Services Supported on Volume Types 
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- iFolder 3.7 - iFolder 3.7 - NetStorage - iFolder 2.1x 
- NetStorage - NetStorage - Novell Client (NCP) - NetStorage 
- Novell Client (NCP) - Novell AFP - NFS, CIFS, AFP 
- Samba - Novell CIFS - Novell Client (NCP) 
- Novell Client (NCP) 
- Samba 


13.2.3 General Requirements for Data Storage 


Finding the right storage solution requires you to identify your data storage requirements. You might 
want to compare your list of requirements against those described in “Storage Solutions" in the NW 
6.5 SP8: Storage and File Services Overview. 


13.2.4 OES 2 Linux Storage Planning Considerations 


Not all data is the same. Not all workloads are the same. Not all file systems are the same. Matching 
your data and workloads to the available file systems and their capabilities lets you build efficient, 
scalable, and cost-effective solutions. This section discusses issues to consider when planning your 
file systems on OES 2 Linux servers, and includes the following topics: 

* "The Workgroup Environment" on page 131 

* "File System Support" on page 132 

* "File Access Protocol Support" on page 134 

* "OES 2 Linux Workloads" on page 135 


The Workgroup Environment 


When selecting a file system, it is important to understand the environment in which it operates. For 
OES 2 Linux, the primary target environment is the workgroup, which requires the following: 


* A shared file system for Linux, Macintosh, and Windows desktops. Think of this as a NAS 
(network-attached storage) for desktops. 
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* A rich, flexible permissions model to maintain security while providing for the management of 
many different users with different permissions throughout the file system. The permissions 
must be granular, allow for delegation of permission management, and ease the administrative 
burden in an environment where change is constant. 


* A robust enterprise-wide identity management system tied into authentication and file system 
permissions is a must. 


¢ The capabilities for correcting end user mistakes that are made daily (accidental overwrites, 
deletes, etc.). 


¢ Integration with collaboration tools. 

¢ Data encryption on an individual user or group basis for compliance and security. 
* Departmental Web servers and databases. 

* SAN support to provide flexible storage management. 


* Backup support for both desktop and server data, with rich tools for monitoring the health of 
the backup system and quickly locating and repairing problems with data protection. 


* Regulatory compliance. Regulatory requirements are now pushing new models of protecting 
and storing employee-generated data that is in LAN systems. It is important to apply correct 
regulatory requirements only on those users to which they must be applied, and then to produce 
audits showing compliance. 


* Highly available collaboration (e-mail) services, with rich tools to monitor, audit, and trend 
resource usage. 


File System Support 


OES 2 Linux offers support for four file systems: Novell Storage Services (NSS), Ext3, ReiserFS, 
and XFS. Following is an explanation of each file system and the pros and cons of using them in the 
workloads supported by OES 2. 

* "Novell Storage Services (NSS)" on page 132 

* “Ext2” on page 133 

* "Ext3" on page 133 

* "ReiserFS" on page 133 

* "XFS" on page 134 


Novell Storage Services (NSS) 


* Supported only through EVMS; not currently supported through LVM. 

* Best for shared LAN file serving; excellent scalability in the number of files 

* Journaled 

* Novell Trustee Model and NSS directory and file attributes (such as Rename Inhibit) provide 


access control that is much richer than POSIX 


The Novell Storage Services file system is used in NetWare 5.0 and above, and most recently is open 
sourced and included in the SUSE? Linux Enterprise Server (SLES) 9 SP1 Linux distribution and 
later (used in the Novell Open Enterprise Server Linux product). 
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The NSS file system is unique in many ways, especially in its ability to manage and support shared 
file services from simultaneous different file access protocols. It is designed to manage access 
control (using a unique model, called the Novell Trustee Model, that scales to hundreds of thousands 
of different users accessing the same storage securely) in enterprise file sharing environments. 


NSS and its predecessor NWFS are the only file systems that can restrict the visibility of the 
directory tree based on the user ID accessing the file system. NSS and NWFS have built-in ACL 
(access control list) rights inheritance. NSS includes mature and robust features tailored for the file- 
sharing environment of the largest enterprises. The file system also scales to millions of files in a 
single directory. NSS also supports multiple data streams and rich metadata; its features are a 
superset of existing file systems on the market for data stream, metadata, name space, and attribute 
support. 


Ext2 


* Legacy file system 

* Not journaled 

* POSIX access control 
Ext2 does not maintain a journal, so it is generally not desirable to use it for any server that needs 
high availability, with one important exception. If the server is running as a Xen VM guest, you 
should format the /boot partition with Ext2 as explained in “Paravitual Mode and Journaling File 
Systems" (http://www.novell.com/documentation/sles10/xen admin/data/sec xen filesystem.html) 


in the Virtualization with Xen (http://www.novell.com/documentation/sles10/xen admin/data/ 
bookinfo.html) guide. 


Ext3 


* Most popular Linux file system; limited scalability in size and number of files 
* Journaled 
* POSIX extended access control 
The Ext3 file system is a journaled file system that has the widest use in Linux today. It is regarded 


by many in the Linux user community as the default Linux file system. It is quite robust and quick, 
although it does not scale well to large volumes or a great number of files. 


A scalability feature has been added called H-trees, which significantly improved Ext3's scalability. 
However, it is still not as scalable as some of the other file systems. With H-trees, it scales similarly 
to NTFS. Without H-trees, Ext3 does not handle more than about 5,000 files in a directory. 


ReiserFS 


* Best performance and scalability when the number of files is great and/or files are small 
* Journaled 
* POSIX extended access control 

The Reiser file system is the default file system in SUSE Linux distributions. ReiserFS was 


designed to remove the scalability and performance limitations that exist in Ext2 and Ext3 file 
systems. 
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Reiser scales and performs extremely well on Linux, outscaling Ext3 with H-trees. In addition, 
Reiser was designed to use disk space very efficiently. As a result, it is the best file system on Linux 
where there are a great number of small files in the file system. Because collaboration (e-mail) and 
many Web servings applications have many small files, Reiser is best suited for these types of 
workloads. 


XFS 


¢ Best for extremely large file systems, large files, and lots of files 
* Journaled (an asymmetric parallel cluster file system version is also available) 


* POSIX extended access controls 


The XFS file system is open source and is included in major Linux distributions. It originated from 
SGI (Irix) and was designed specifically for large files and large volume scalability. 


Video and multimedia files are best handled by this file system. Scaling to petabyte volumes, it also 
handles very large amounts of data. It is one of the few file systems on Linux that supports HSM 
data migration. 


File Access Protocol Support 
OES 2 Linux offers support for a variety of file access protocols. 


* AFP: The Apple Filing Protocol (AFP) is a network protocol that offers file services for Mac 
OS X and the original Mac OS. 


* CIFS (Novell CIFS and Samba): The Common Internet File Services (CIFS) protocol is the 
protocol for Windows networking and file services. 


Novell CIFS is a ported version of the CIFS file service traditionally available only on NetWare 
but now available for OES 2 Linux starting with SP1. 


Samba is an open source software version of CIFS based on extensive use and analysis of the 
wire protocol of Microsoft Windows machines. 


* FTP: The File Transfer Protocol (FTP) is one of the most common and widely used simple 
protocols in the Internet. Virtually all platforms and devices support FTP at some level, but it is 
a very simple protocol, only allowing for uploading and downloading of files. 


* HTTP: The Hypertext Transfer Protocol (HTTP) is the dominant protocol on the World Wide 
Web today, and is the one “spoken” by Web browser clients and Web servers. It is like FTP in 
being designed strictly for transfers of HTML (Hypertext Markup Language) and additional 
markup languages that have been invented, such as XML (Extensible Markup Language). 


* NCP: The NetWare Core Protocol (NCP) is the client server protocol developed by Novell for 
supporting DOS, Windows, OS/2*, Macintosh, UNIX* (UnixWare*), and Linux for shared file 
services. 


The NCP Server on Linux includes emulation for the Novell Trustee Model and inheritance 
plus visibility when it runs on traditional POSIX file systems such as Ext3 and Reiser. When it 
runs on NSS on Linux, these capabilities are synchronized with the NSS File system and its 
extended directory and file attributes, such as Rename Inhibit. 


134 NW 6.5 SP8: Planning and Implementation Guide 


OES 2 Linux Workloads 


Each file system has its strengths and weaknesses depending on the workload the file system 
supports. This section gives some guidelines for picking and building the right file system for a 
given workload. In determining which file system to use for a particular workload, consider your 
environment and the following explanation of each workload to determine which file system best 
meets your workload environment. 


Table 13-2 File System Support per Workload 


Workload Type 


NSS File System 


Ext3 File System 


Reiser File System XFS File System 


File serving — Supported Supported Recommended Recommended 
Application server 

File serving — end user Recommended Supported Supported Supported 

files 

Network printing Recommended Recommended Recommended Recommended 
(iPrint) 

iFolder Recommended Supported Recommended Recommended 
Collaboration Recommended Supported Recommended Recommended 
(GroupWise? ) 

Cluster services Supported Supported Supported Supported 
Dynamic Storage Supported Not Supported Not Supported Not Supported 


Technology 


The following sections provide a brief summary of considerations for each workload listed in Table 
13-2. 


File Serving (NAS) 


Generally there are two types of NAS use cases: Serving files to application servers in a tiered 
service oriented architecture (SOA), and serving files to end user desktops and workstations. The 
former has minimal access control requirements. The latter has quite heavy access control 
requirements. 


Typically for serving files to application servers (traditional NAS), you would choose a file system 
that is scalable and fast. Reiser and XFS would be good choices in this environment. For file serving 
to end user workstations, the access control and security management capabilities of the NSS file 
systems with CIFS and NCP file access protocols are important. 


The NSS model does better than the other file systems for very large numbers of users. It allows for 
security between users and also allows for very fine granular sharing between given users and 
groups. NSS includes a visibility feature implemented in the file system that prevents unauthorized 
users from even seeing subdirectory structures they don't have rights to access. 


Network Printing (iPrint) 


iPrint is file system agnostic. There is no noticeable difference in performance or reliability on any 
of the file systems. 


Storage and File Systems 


135 


iFolder 


Novell iFolder does not depend on a particular file system. Based on the client workload, the file 
system should be chosen at the server side. Because it mostly serves user data, a file system that can 
scale with a large number of files is the best suited in most deployments, making Reiser and NSS the 
best bets. Novell iFolder maintains its own ACL, so having an NSS file system that supports a rich 
ACL might be redundant. 


GroupWise 


Group Wise deals with many little files. Because only the application process is accessing the file 
system, the added overhead of the rich ACL and file attributes found in NSS is redundant. The 
necessary characteristics are a file system whose performance remains relatively constant regardless 
of the number of files that are in the volume, and that performs well with small files. Best bets would 
be ReiserFS, XFS, and NSS. Ext3 does not handle large systems well (where you have more than 
10,000 files in the system). 


Novell Cluster Services 


Although Novell Cluster Services™ does not depend on a particular file system, you must use the 
same file systems from node to node. For example, if you are using NSS on one node, you need to 
use NSS on the failover node as well. 


Dynamic Storage Technology 


Dynamic Storage Technology does not depend on a particular file system in principle; however, it is 
currently supported only on NSS volumes. 


Novell plans to add support for additional file systems in the future. When that happens, it will be 
important to remember that file systems cannot be mixed between volumes and shadow volumes. 
For example, if you choose to shadow an NSS volume, the secondary volume must also be NSS. 


13.2.5 NSS Planning Considerations 


Consider the following when planning for NSS: 
* “Device Size Limit" on page 136 
* "Other NSS Planning Topics" on page 136 
Device Size Limit 


NSS recognizes logical or physical devices up to 2 terabytes (TB) in size. If you have a storage disk 
larger than 2 TB, use the storage device's management utility to carve the disk into smaller logical 
devices to use with the NSS file system. 


This is especially important to remember when planning for NSS volumes on Linux because the size 
limit for Linux POSIX volumes is 8 TB. 


Other NSS Planning Topics 


To plan for NSS volumes—including prerequisites, security considerations, and moving volumes 
between Linux and NetWare—see “Planning NSS Storage Solutions” in the NW 6.5 SP8: NSS File 
System Administration Guide. 
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13.3 Coexistence and Migration of Storage 
Services 


The following sections summarize the coexistence and migration issues related to storage services. 


* Section 13.3.1, “MySQL,” on page 137 
* Section 13.3.2, “OES 2 Linux Options," on page 137 
* Section 13.3.3, *OES 2 NetWare Options," on page 138 


13.3.1 MySQL 


OES 2 includes the open source MySQL database server on both the NetWare and Linux platforms. 
When combined with a Web application and a Web server, MySQL is a very reliable and scalable 
database for use in hosting e-commerce and business-to-business Web applications. 





NOTE: The more powerful PostgreSQL database server comes with SUSE Linux Enterprise 
Server 10. It has also been ported to the NetWare platform and is available separately as open source 
software. 





13.3.2 OES 2 Linux Options 


OES 2 Linux provides support for Novell Storage Services (NSS) as well as Linux POSIX file 
systems. 


* "NSS Volumes" on page 137 
* "Linux POSIX File Systems" on page 138 


NSS Volumes 
NSS volumes are cross-compatible between NetWare and Linux. 


To use NSS on OES 2 Linux, you must have a disk available to be managed by Enterprise Volume 
Management System (EVMS). The boot partition (such as /boot for Grub) and system partition 
(such as for the swap and system volumes) are managed by Logical Volume Manager 2 (LVM2). 
Any disk managed by LVM2 cannot be managed by EVMS, which makes the disks where the boot 
partition and system partition reside unavailable to NSS. 


If you have a single-disk server that you want to install OES 2 for Linux on and create an NSS 
volume, see "Installing with EVMS as the Volume Manager of the System Device" in the OES 2 
SP2: Installation Guide. 


On OES 2 Linux, you can use NSS volumes only as data volumes. Configure NSS pools and 
volumes in iManager or NSSMU after the server installation completes successfully. 


Starting with OES 1 SP1 NetWare and OES 2 Linux, a new metadata structure provides enhanced 
support for hard links. After you install or upgrade your operating system, you must upgrade the 
media format in order to use the new metadata structure; some restrictions apply. For more 
information, see "Upgrading the NSS Media Format" in the NW 6.5 SP8: NSS File System 
Administration Guide. 
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For additional information about coexistence and migration of NSS volumes, as well as access 
control issues for NSS on Linux, see “Cross-Platform Issues for NSS” in the NW 6.5 SP8: NSS File 
System Administration Guide. 


Linux POSIX File Systems 


You can install NCP Server for Linux to provide NetWare Core Protocol access to Linux POSIX file 
systems. This allows users running the Novell Client software to map drives to the Linux file system 
data, with access controls being enforced by NCP. 


For more information on using NCP Server for Linux in OES, see the OES 2 SP2: NCP Server for 
Linux Administration Guide. 


Users can access data storage on OES 2 NetWare and OES 2 Linux servers through a number of 
methods. For more information, see "Overview of File Services” on page 187. 


13.3.3 OES 2 NetWare Options 


OES 2 NetWare supports both the NetWare Traditional file system and Novell Storage Services 
(NSS). 


* "NetWare Traditional File System" on page 138 
* "NSS Volumes" on page 138 


NetWare Traditional File System 


After upgrading an older NetWare server to OES 2 NetWare, it is possible for a NetWare Traditional 
file system volume to still reside on that server. You can continue to use Traditional volumes with 
OES 2 NetWare, or you can upgrade them to NSS. 


For information on converting Traditional volumes to NSS, see *Upgrading NetWare 5.1 NSS 
Volumes and NetWare Traditional Volumes to NSS Volumes" in the NW 6.5 SP8: NSS File System 
Administration Guide. 


If you want to migrate data from a Traditional volume to an NSS volume on OES 2 Linux, use the 
Novell Server Consolidation Utility 4.0 or later. You must first install NFS name space support on 
the Traditional volume. 


For more information on migrating data from NetWare to Linux, see “Understand NetWare-to-Linux 
Data Migration Issues" in the Novell Server Consolidation and Migration Toolkit Administration 
Guide. 


You can upgrade both NetWare Traditional volumes and Legacy NSS volumes to OES 2. 


For more information, see "Upgrading Legacy NSS and NetWare Traditional Volumes" in the NW 
6.5 SP8: NSS File System Administration Guide. 


NSS Volumes 


NSS volumes are cross-compatible between NetWare and Linux servers. You can mount an NSS 
data volume on either kernel —Linux or NetWare—and move it between them as long as they both 
support the same media format. In a clustered SAN, volumes that were originally created on a 
NetWare server can fail over between kernels, allowing for full data and file system feature 
preservation when migrating data to Linux. 
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Supporting NSS volumes in a mixed environment and migrating data between OES platforms 
presents a number of possibilities for your storage solutions. However, to ensure success you must 
fully understand the proper methods and limitations involved. 


For additional information about coexistence and migration of NSS volumes, as well as access 
control issues for NSS on Linux, see “Migrating NSS Devices from NetWare to OES 2 Linux” in the 
NW 6.5 SP8: NSS File System Administration Guide. 


13.4 Initial Setup Is Required for NetWare 


During installation, NetWare creates an NSS system pool (sys) and volume (sys:) on your server’s 
primary hard drive. You must create other NSS pools and volumes before you can use your system 
effectively. For information, see the NW 6.5 SP8: NSS File System Administration Guide. 


13.5 Configuring and Maintaining Storage 


* Section 13.5.1, “Managing Directories and Files,” on page 139 
* Section 13.5.2, “Managing NSS,” on page 139 
* Section 13.5.3, *Optimizing Storage Performance," on page 141 


* Section 13.5.4, “Disk Management on NetWare,” on page 141 


13.5.1 Managing Directories and Files 


To learn about managing directories and files for the OES 2 server type, see the following sections in 
the NW 6.5 SP8: File Systems Management Guide. 

* Linux: "Understanding Directory Structures in Linux POSIX File Systems" 

* NetWare: "Managing Folders and Files on NSS and NetWare Traditional Volumes" 


13.5.2 Managing NSS 


Use the links in Table 13-3 to find information on the many management tasks associated with NSS 
volumes. 


Table 13-3 NSS Management 


Category/Feature Description Link 


Archive and Version Use Archive and Version Services with OES 2 SP2: Novell Archive and 
Services NSS volumes to save interval-based Version Services 2.1 for Linux 
copies of files that can be conveniently Administration Guide 


restored by administrators and users. 
NW 6.5 SP8: Novell Archive and 


Version Services 2.1 Administration 





Guide 
Compression Conserve disk space and increase the “Managing Compression on NSS 
amount of data a volume can store. Volumes" in the NW 6.5 SP8: NSS File 


System Administration Guide 
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Category/Feature 


Console Commands 


Description 


Manage NSS volumes at an OES 2 
NetWare server console, or an OES 2 
Linux terminal console via the NSS 
Console (nsscon) utility. 


Link 


“NSS Commands” and “NSS Utilities” 
in the NW 6.5 SP8: NSS File System 
Administration Guide 





Distributed File 
Services (DFS) 


Use DFS junctions to transparently 
redirect data requests, split volumes 
while maintaining transparent access, 
and quickly move volume data to 
another volume. 


NW 6.5 SP8: Novell Distributed File 
Services Administration Guide 





Encryption 


EVMS 


Create and manage encrypted NSS 
volumes that make data inaccessible to 
software that circumvents normal 
access control. 


Use EVMS, which is required for NSS, 
to manage volumes on Linux, including 
the system (root [/]) volume if NSS is 
installed on the same disk. 


“Managing Encrypted NSS Volumes" 
in the NW 6.5 SP8: NSS File System 
Administration Guide 


“Using EVMS to Manage Devices with 
NSS Volumes (Linux)” in the NW 6.5 
SP8: NSS File System Administration 
Guide 





Hard Links 


Create multiple names for a single file 
in the same or multiple directories in an 
NSS volume. 


“Managing Hard Links” in the NW 6.5 
SP8: NSS File System Administration 
Guide 





Monitoring 


Monitor NSS file systems. 


“Monitoring the Status of the NSS File 
System and Services" in the NW 6.5 
SP8: NSS File System Administration 
Guide 





Multipath Support 


Manage the dynamic, multiple, 


“Managing Multipath I/O to Devices 











(NetWare) redundant connection paths NSS (NetWare)” in the NW 6.5 SP8: NSS 
creates between a NetWare server and File System Administration Guide 
its external storage devices. 
Partitions Manage partitions on NSS volumes. "Managing Partitions" in the NW 6.5 
SP8: NSS File System Administration 
Guide 
Pools Create and manage NSS pools. "Managing NSS Pools" in the NW 6.5 
SP8: NSS File System Administration 
Guide 
Quotas Set space restrictions for users and "Managing Space Quotas for Volumes, 


directories to control storage usage. 


Directories, and Users" in the NW 6.5 
SP8: NSS File System Administration 
Guide 





Salvage subsystem 


Use the salvage subsystem to make 
deleted files and directories available 
for undelete or purge actions. 


“Salvaging and Purging Deleted 
Volumes, Directories, and Files" in the 
NW 6.5 SP8: NSS File System 
Administration Guide 





Tools 


Learn about the various tools available 
to manage NSS volumes, the tool 
capabilities, and how to use them. 
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"Management Tools for NSS” in the 
NW 6.5 SP8: NSS File System 
Administration Guide 


Category/Feature 


Troubleshooting 


File System Trustees 
and Attributes 


Description 


Troubleshoot NSS on OES 2 Linux and 
OES 2 NetWare. 


Control user access to data by setting 
trustees, trustee rights, and inherited 
rights filters for files. Control file 
behavior by setting file and folder 
attributes. 


Link 


“Troubleshooting the NSS File 
System’ in the NW 6.5 SP8: NSS File 
System Administration Guide 


“Configuring File System Trustees, 
Trustee Rights, Inherited Rights 
Filters, and Attributes” in the NW 6.5 
SP8: NSS File System Administration 
Guide 





Volumes 


Create and manage NSS volumes in 
NSS pools. 


“Managing NSS Volumes” in the NW 
6.5 SP8: NSS File System 
Administration Guide 


13.5.3 Optimizing Storage Performance 


* NSS on Linux: “Tuning NSS Performance on Linux” in the NW 6.5 SP8: NSS File System 
Administration Guide 


* NSS on NetWare: “Tuning NSS Performance on NetWare” in the NW 6.5 SP8: NSS File 
System Administration Guide 


13.5.4 Disk Management on NetWare 


Disk management is obviously central to providing storage services. To plan how you will add, 
allocate, maintain, and remove disks accessed by OES 2 NetWare servers, see NW6.5 SP8: Server 
Disks and Storage Devices. 
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eDirectory, LDAP, and Domain 
Services for Windows 


This section discusses the following topics: 


* Section 14.1, “Overview of Directory Services,” on page 143 
¢ Section 14.2, “eDirectory,” on page 144 
* Section 14.3, "LDAP (eDirectory)," on page 145 


¢ Section 14.4, “Domain Services for Windows,” on page 146 


14.1 Overview of Directory Services 


Storing and managing network identities in directory services is a fundamental expectation for 
networking. 


In the simplest terms, Novell® eDirectory™ is a tree structure containing a list of objects (or 
identities) that represent network resources, such as the following: 

* Network users 

* Servers 

* Printers 

* Applications 
eDirectory is designed to provide easy, powerful, and flexible management of network resources 


(including eDirectory itself) in ways that no other directory service can match. You can administer 
eDirectory through the same browser-based tools on both OES platforms. 


For more information, see Chapter 14, “eDirectory, LDAP, and Domain Services for Windows,” on 
page 143. 
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Figure 14-1 eDirectory Overview 


Users Br d Authentication Services js Servers 


Identity and Directory 
Services 


Identities 





Admin users 


n (Directory objects) 
Browser-based tools 


eDirectory 
(including LDAP) 





eDirectory servers OES 2 servers 


14.2 eDirectory 


Novell eDirectory is the central, key component of Novell Open Enterprise Server (OES) and 
provides the following: 


¢ Centralized identity management 
¢ The underlying infrastructure for managing your network servers and the services they provide 


* Access security both within the firewall and from the Web 
This section discusses the following tasks: 


* Section 14.2.1, "Installing and Managing eDirectory on OES," on page 144 
* Section 14.2.2, "Planning Your eDirectory Tree," on page 145 


* Section 14.2.3, "eDirectory Coexistence and Migration," on page 145 


14.2.1 Installing and Managing eDirectory on OES 


The tools you can use to install and manage eDirectory on OES are outlined in the following 
sections. 


+ “OES Installation Programs" on page 144 
+ “iManager” on page 145 
OES Installation Programs 


OES requires that eDirectory be installed by using the NetWare® Install or the YaS T-based install 
for OES Linux. 


144 NW 6.5 SP8: Planning and Implementation Guide 





IMPORTANT: Other utilities, such as ndsconfig and ndsmanage, are not supported for installing or 
removing eDirectory on OES servers. 





iManager 


iManager is the OES eDirectory management tool and is used for all eDirectory management and 
most OES component management tasks, including the following: 


¢ Creating eDirectory objects, including User and Group objects 
* Managing eDirectory objects 
¢ Configuring and managing OES service component controls in eDirectory 


* Accessing other OES component management tools 


For information on using iManager, see the Novell iManager 2.7.3 Administration Guide. 


14.2.2 Planning Your eDirectory Tree 


If you don't have eDirectory installed on your network, it is critical that you and your organization 
take time to plan and design your eDirectory tree prior to installing OES. 


The OES 2 SP2: Lab Guide for Linux and Virtualized NetWare provides an introduction to 
eDirectory planning that you might find useful for getting started with eDirectory. 


For detailed information on getting started using eDirectory, see “Designing Your Novell eDirectory 
Network" in the Novell eDirectory 8.8 Installation Guide. 


To learn what's new in eDirectory 8.8, see the Novell eDirectory 8.8 What&apos;s New Guide. 


14.2.3 eDirectory Coexistence and Migration 


Novell Directory Services? (NDS®) was introduced with NetWare 4.0. The successor to NDS, 
Novell eDirectory, is also available for Microsoft Windows, Red Hat’, and SUSE® versions of 
Linux, as well as various flavors of UNIX (Solaris", AIX’, and HP-UX’). 


As eDirectory has evolved, backward compatibility issues have arisen. For example, moving from 
NetWare 4.x to 5.x involved not only upgrading NDS, but also moving from IPX™ to TCP/IP. This 
transition brought significant changes to the core schema and security-related components. Novell 
has consistently provided the migration tools and support required to migrate to new eDirectory 
versions. 


OES 2 Linux includes eDirectory 8.8. For those upgrading an existing OES 1 SP2 NetWare 
(NetWare 6.5 SP6) server, eDirectory 8.7.3 is still available. New NetWare installations require 
eDirectory version 8.8. 


For complete coexistence and migration information and instructions, see “Migrating to eDirectory 
8.8 SP3 " in the Novell eDirectory 8.8 Installation Guide. 


14.3 LDAP (eDirectory) 


This section contains information about LDAP support in OES. 


* Section 14.3.1, "Overview of eDirectory LDAP Services,” on page 146 
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* Section 14.3.2, “Planning eDirectory LDAP Services,” on page 146 
* Section 14.3.3, “Migration of eDirectory LDAP Services,” on page 146 
* Section 14.3.4, “eDirectory LDAP Implementation Suggestions,” on page 146 


14.3.1 Overview of eDirectory LDAP Services 


Lightweight Directory Access Protocol (LDAP) Services for Novell eDirectory is a server 
application that lets LDAP clients access information stored in eDirectory. 


Most OES 2 services leverage the LDAP server for eDirectory for authentication, as illustrated in 
the service overviews in this guide. 


14.3.2 Planning eDirectory LDAP Services 


LDAP for eDirectory provides LDAP authentication for the objects stored in eDirectory. As you 
plan your eDirectory tree, be sure you understand the information in “Understanding LDAP 
Services for Novell eDirectory” in the Novell eDirectory 8.8 Administration Guide. 


14.3.3 Migration of eDirectory LDAP Services 


If you have users in an OpenLDAP database and you want to migrate them to eDirectory, you can 
use the Novell Import Conversion Export (ICE) utility. For more information, see “Novell 
eDirectory Management Utilities” in the Novell eDirectory 8.8 Administration Guide. 


14.3.4 eDirectory LDAP Implementation Suggestions 


For help with setting up and using LDAP for eDirectory, refer to “Configuring LDAP Services for 
Novell eDirectory” in the Novell eDirectory 8.8 Administration Guide. 


14.4 Domain Services for Windows 


Novell Domain Services for Windows (DSfW) allows eDirectory users on Windows workstations to 
access storage on both OES servers and Windows servers through native Windows and Active 
Directory authentication and file service protocols. 


DSfW enables companies with Active Directory and Novell eDirectory deployments to achieve 
better coexistence between the two platforms. 


* Users can work in a pure Windows desktop environment and still take advantage of some OES 
back-end services and technology, without the need for a Novell Client™ or even a matching 
local user account on the Windows workstation. 


* Network administrators can use Microsoft Management Console (MMC) to administer users 
and groups within the DSfW domain, including their access rights to Samba-enabled storage on 
OES servers. 


This section discusses the following: 


* Section 14.4.1, “Graphical Overview of DSfW,” on page 147 
* Section 14.42, “Planning Your DSfW Implementation,” on page 150 
* Section 14.4.3, “Implementing DSfW on Your Network,” on page 150 
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14.4.1 Graphical Overview of DSfW 


* “File Access” on page 147 
* "User Management" on page 148 


* "Storage Management" on page 149 


File Access 


Figure 14-2 DSfW File Access Overview 
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Table 14-1 DSfW File Access 


Access Methods Authentication File Storage Services 


eDirectory and Active Directory users on For eDirectory users, file service On OES 2 servers, file 


Windows workstations can access files access is controlled by storage services are 
through Windows Explorer (CIFS) or authentication through the provided by Samba to NSS 
Internet Explorer (WebDAV Web eDirectory server using common or trandtional Linux file 
Folders). No Novell Client can be on the Windows authentication systems. 
machine. protocols, including Kerberos*, 

NTLM, and SSL/TLS. For eDirectory users, 
Unlike Windows workgroup or Novell access to storage on 
Samba, the user doesn't need to have a For AD users, file service access Windows servers is 
matching username and password on is controlled by authentication available through a cross- 
the local workstation. through the AD server. forest trust. Access rights 

are granted by the AD 

Although not shown, Novell Client users administrator following the 
can also access files through a normal establishment of the cross- 
NCP™ connection. forest trust. 


User Management 


Figure 14-3 DSfW User Management Overview 
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Table 14-2 DSfW User Management 


Management Tools Users 

iManager manages DSfW users like DSfW users must have the Default Domain Password policy 
other eDirectory users. assigned and a valid Universal Password. 

MMC manages both AD users and DSfW users are automatically enabled for Samba and LUM. 
DSfW users as though they were AD 

users. 


Storage Management 


Figure 14-4 DSfW Storage Management Overview 
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Table 14-3 DSfW Storage Management 


Management Tools Storage 


Network administrators use native OES Storage devices on OES 2 servers can be either NSS or 
and Windows storage management traditional Linux volumes. Samba management standards 
tools to create and manage storage apply to both volume types. 

devices on OES and Windows servers, 

respectively. 


Windows management tools can also 
manage share access rights and POSIX 
file system rights on DSfW storage 
devices after the shares are created. 
They cannot create the shares or 
perform other device management 
tasks. 


14.4.2 Planning Your DSfW Implementation 


For planning information, see the OES 2 SP2: Domain Services for Windows Administration Guide. 


14.4.3 Implementing DSfW on Your Network 


This section highlights some of the potential caveats to consider when installing DSfW. For 
complete information, see the OES 2 SP2: Domain Services for Windows Administration Guide, 
especially the “Troubleshooting DSfW” section. 

* "Universal Password in a Name-Mapped Scenario" on page 150 

* “DSfW Must Be Installed at the Root of an eDirectory Partition" on page 150 

* "Hierarchical Placement of Users in the eDirectory Tree" on page 151 

+ “OES 2 Service Limitations" on page 151 

* "Domain and Container Names Must Match" on page 151 

+ “Install DSfW on a New OES 2 Linux Server When Possible” on page 151 

* “DNS Configuration" on page 151 


Universal Password in a Name-Mapped Scenario 


If you install DSfW into an existing tree and your users don't currently have a Universal Password 
policy assigned, they won't be able to log in without the Novell Client until the Universal Password 
has been set. 


Therefore, you should consider implementing Universal Password and giving users an opportunity 
to log into the network before installing DSfW. Logging in after a password policy is in place creates 
a Universal Password for users so that their transition to DSfW is seamless. 


DSfW Must Be Installed at the Root of an eDirectory Partition 


You must install DSfW in the root container or an eDirectory partition, either one that currently 
exists or one that you create for DSfW. In both cases, the first DSfW server installed in the partition 
becomes the master of the partition. 
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Hierarchical Placement of Users in the eDirectory Tree 


DSfW users must reside in the same eDirectory partition where DSfW is installed, either in the same 
container or in a container below it in the hierarchy. Therefore, DSfW should be installed high 
enough in the eDirectory tree that it encompasses all of the users that you want to enable for DSfW 
access. 


OES 2 Service Limitations 


Only designated OES 2 services can be installed on a DSfW server. For more information, see 
“Unsupported Service Combinations” in the OES 2 SP2: Domain Services for Windows 
Administration Guide. 


Domain and Container Names Must Match 


When you install DSfW, the Domain name you specify must match the name of the container you 
are installing into. For more information, see "Installing the First DSfW Server in a New eDirectory 
Tree" in the OES 2 SP2: Domain Services for Windows Administration Guide. 


Install DSfW on a New OES 2 Linux Server When Possible 


Because of the service limitations mentioned in OES 2 Service Limitations, Novell strongly 
recommends that you install DSfW on a new server. 


DNS Configuration 
As you set up DNS, observe the following guidelines: 


* First DSfW Server (FRD): This should point to itself as the primary DNS server, and to the 
network DNS server as the secondary DNS server (if applicable). 


* Subsequent DSfW Servers: These must point to the FRD as their primary DNS server and 
optionally to the network DNS server as their secondary DNS server. 


* DSfW Workstations: These must be able to resolve the FRD of the DSfW forest. For 
example, you might configure workstations to point to the FRD as their primary DNS server 
and to the network DNS server secondarily. Or if the network DNS server is configured to 
forward requests to the DSfW server, then workstations could point to it as their primary DNS 
server. 
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Users and Groups 


Networks exist to serve users and groups of users. Open Enterprise Server 2 provides strong user 
and group management through eDirectory™ and its associated technologies. 
* Section 15.1, “Creating Users and Groups," on page 153 
* Section 15.2, “Linux User Management: Access to Linux for eDirectory Users,” on page 153 
* Section 15.3, “Identity Management Services," on page 162 


* Section 15.4, “Using the Identity Manager 3.5 Bundle Edition,” on page 163 


15.1 Creating Users and Groups 


All OES 2 services require that you create User objects to represent the users on your system. The 
Linux User Management (LUM) and Samba components on OES 2 Linux also require that you 
create a LUM-enabled Group object that you can assign the users to. 


In addition to these basic objects, it is usually helpful to organize your tree structure by using 
Organizational Unit objects to represent the structure of your organization and to serve as container 
objects to help manage the users, groups, servers, printers, and other organization resources you 
manage through eDirectory. 


The Lab Guide for OES 2 Linux provides basic instructions for creating container objects as well as 
Group and User objects in eDirectory. 


For more information about Samba, see Creating eDirectory Users for Samba in the OES2 SP2: 
Samba Administration Guide. 


For detailed information on understanding, creating, and managing the various objects your 
organization might require, see the Novell eDirectory 8.8 Administration Guide. 


15.2 Linux User Management: Access to Linux 
for eDirectory Users 


Users and groups on NetWare® servers are created in and managed through eDirectory; users and 
groups on Linux servers are usually created locally and managed according to the POSIX (Portable 
Operating System Interface) standard. 


Because Open Enterprise Server provides services running on both Linux and NetWare, Novell® has 
developed a technology that lets eDirectory users also function as “local” POSIX users on Linux 
servers. This technology is called Linux User Management or LUM. 


The following sections outline the basic principles involved in Novell LUM and cover the following 
topics: 

* Section 15.2.1, “Overview,” on page 154 

* Section 15.2.2, “Planning,” on page 159 

* Section 15.2.3, “Coexistence and Migration,” on page 160 


* Section 15.2.4, “LUM Implementation Suggestions," on page 160 
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15.2.1 Overview 


The topics in this section are designed to help you understand when LUM-enabled access is required 
so that your network services are accessible and work as expected. For more information about 
Linux User Management, see “Overview” in the OES 2 SP2: Novell Linux User Management 
Technology Guide. 

* “A Graphical Preview of Linux User Management" on page 154 

* "Linux Requires POSIX Users" on page 155 

* "Linux Users Can Be Local or Remote" on page 155 

* “The root User Is Never LUM-Enabled" on page 155 

* "About Service Access on OES 2 Linux" on page 156 

* "Services in OES 2 Linux That Require LUM-Enabled Access" on page 156 


* "Services That Do Not Require LUM-Enabled Access But Have Some LUM Requirements” on 
page 158 


* "Services That Do Not Require LUM-enabled Access" on page 158 
* "LUM-Enabling Does Not Provide Global Access to ALL OES 2 Linux Servers" on page 159 


A Graphical Preview of Linux User Management 


Figure 15-1 illustrates how Linux User Management controls access to the OES 2 server. 


Figure 15-1 LUM Provides POSIX Access for eDirectory Users 
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The following table explains the information presented in Figure 15-1. 
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Table 15-1 Linux User Management 


Valid POSIX Users Authentication eDirectory Authenticated Services 
Some services on OES 2 Linux When the system receives an Users can potentially access 
servers must be accessed by action request, it can authenticate PAM-enabled services, Samba 
POSIX users. both local POSIX users and users shares, and Novell Remote 

who have been enabled for Linux Manager as either local or 
eDirectory users can function aS — access. eDirectory users. 
POSIX users if they are enabled 
for Linux access (LUM). By default, only the openwbem 


command (required for server 
management) is enabled for 
eDirectory access. 


Linux Requires POSIX Users 


Linux requires that all users be defined by standard POSIX attributes, such as username, user ID 
(UID), primary group ID (GID), password, and other similar attributes. 


Linux Users Can Be Local or Remote 
Users that access a Linux server can be created in two ways: 


* Locally (on the server): Local users are managed at a command prompt (using commands 
such as useradd) or in YaST. (See the useradd(8) man page and the YaST online help for more 
information.) These local users are stored in the /etc/passwd file. (See the passwd(5) man 
page for more information.) 





IMPORTANT: As a general rule on OES 2 Linux servers, the only local user account that 
should exist is root. All other user accounts should be created in eDirectory and then be 
enabled for Linux access (LUM). You should never create duplicate local and eDirectory user 
accounts. 


For more information, see Section 6.1, *Avoiding POSIX and eDirectory Duplications," on 
page 59. 


* Remotely (off the server): Remote users can be managed by other systems, such as LDAP- 
compliant directory services. Remote user access is enabled through the Pluggable 
Authentication Module (PAM) architecture on Linux. 


The Linux POSIX-compliant interfaces can authenticate both kinds of users, independent of where 
they are stored and how they are managed. 


The root User Is Never LUM-Enabled 


The OES 2 user management tools prevent you from creating an eDirectory user named root, thus 
replacing the root user on an OES 2 Linux server. If root were to be a LUM user and eDirectory 
became unavailable for some reason, there would be no root access to the system. 


Even if eDirectory is not available, you can still log into the server through Novell Remote Manager 
and perform other system management tasks as the root user. 
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About Service Access on OES 2 Linux 


Novell Linux User Management (LUM) lets you use eDirectory to centrally manage remote users 
for access to one or more OES 2 Linux servers. 


In other words, LUM lets eDirectory users function as local (POSIX) users on an OES 2 Linux 
server. Access is enabled by leveraging the Linux Pluggable Authentication Module (PAM) 
architecture. PAM makes it possible for eDirectory users to authenticate with the OES 2 Linux 
server through LDAP. 


In OES, the terms LUM-enabling and Linux-enabling are both used to describe the process that adds 
standard Linux (POSIX) attributes and values to eDirectory users and groups, thus enabling them to 
function as POSIX users and groups on the server. 


You can use iManager to enable eDirectory users for Linux. For instructions, see “About Enabling 
eDirectory Users for Linux Access” on page 160. 


Services in OES 2 Linux That Require LUM-Enabled Access 
Some services on an OES 2 Linux server require that eDirectory users be LUM-enabled: 


* Novell Samba (CIFS) Shares on the Server: Windows workgroup users who need access to 
Samba shares defined on the server must be LUM-enabled eDirectory users who are configured 
to access the server. This is because Samba requires POSIX identification for access. 


By extension, NetStorage users who need access to Samba (CIFS) Storage Location objects 
that point to the server must also be LUM-enabled eDirectory users with access to the server. 


NOTE: Although Samba users must be enabled for LUM, Samba is not a PAM-enabled 
service. Logging in to the OES 2 Linux server through Samba does not create a home directory. 





* Core Linux Utilities Enabled for LUM: These are the core utilities and other shell 
commands that you can specify during the OES install to be enabled for authentication through 
eDirectory LDAP. In Linux, these are known as PAM-enabled utilities. 





IMPORTANT: Before you accept the default PAM-enabled service settings, be sure you 
understand the security implications explained in Section 21.2.2, “User Restrictions: Some 
OES 2 Linux Limitations," on page 230. 


The core utilities available for LUM-enablement are summarized in Table 15-2. 
Table 15-2 PAM-enabled Services Controlled by LUM 


Command Where Executed Task 


ftp Another host Transfer files to and from the OES 2 server which, 
in this case, is a remote host. 








login * OES 2 server Log in to the OES 2 server, either directly or in an 
+ SSH session with OES 2 SSH session with the server. 
server 
openwbem Local host Required for iPrint, NSS, SMS, Novell Remote 


Manager, and iManager. 
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Command Where Executed Task 


gdm * Local host Run and manage the X servers using XDMCP. 


* Remote host 





gnomesu-pam Local host Required for GNOME applications that need 
superuser access. 


sshd Another host Establish a secure encrypted connection with the 
OES 2 server which, in this case, is a remote host. 
su * OES 2 server Temporarily become another user. 


+ SSH session with OES 2 
server 


This is most often used to temporarily become the 
root user, who is not a LUM user and is, 
therefore, not affected by LUM. 


NOTE: Logging in to the OES 2 Linux server through a PAM-enabled service for the first time 
causes the creation of a home directory on the server. 





* Novell Remote Manager on Linux: You can access Novell Remote Manager as the 
following: 


¢ The root user with rights to see everything on the Linux server. 


¢ A local Linux user with access governed by POSIX access rights. (Having local users in 
addition to root is not recommended on OES 2 servers.) 


* ALUM-enabled eDirectory user, such as the Admin user created during the install. 
* Novell Storage Management Services (SMS) on Linux: You can access SMS utilities as 
¢ The root user with rights to see everything on the Linux server. 


¢ A local Linux user with access governed by POSIX access rights. (Having local users in 
addition to root is not recommended on OES 2 servers.) 


* ALUM-enabled eDirectory user, such as the Admin user created during the install. 
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Services That Do Not Require LUM-Enabled Access But Have Some LUM 
Requirements 


Some services do not require eDirectory users to be LUM-enabled for service access: 


* 


NetStorage: NetStorage users don't generally need to be LUM-enabled. However, salvaging 
and purging files through NetStorage on an NSS volume can only be done by users who are 
enabled for Linux. 





IMPORTANT: Files that are uploaded by non-LUM users via NetStorage are owned, from a 
POSIX perspective, by the root user. The assumption is that such users are accessing their data 
on NSS or NCP™ volumes by using an NCP storage location object. In both cases, the Novell 
Trustee Model applies and POSIX ownership is irrelevant. 


If non-LUM NetStorage users are later enabled for Samba access (which includes LUM- 
enabling) and begin using Samba as a file service, their NetStorage uploaded files are not 
accessible through Samba until you change POSIX file ownership. Although the Novell 
implementation of Samba leverages eDirectory for authentication, Samba file and directory 
access is always controlled by POSIX. The Novell Trustee Model doesn't apply to Samba. 


Both Novell trustee assignments and POSIX file ownership are tracked correctly after users are 
LUM-enabled. 





Although NetStorage doesn’t require LUM-enabled access, the service itself runs as a POSIX- 
compliant system User (initially a local user on the OES 2 Linux server) who functions on 
behalf of the end users that are accessing the service. 


If NetStorage must access NSS volumes, this local system user must be moved to eDirectory 
and LUM-enabled because only eDirectory users can access NSS volumes. The OES 2 
installation program configures this correctly by default. 


For more information, see Appendix I, “System User and Group Management in OES 2 SP1,” 
on page 263. 


NSS: eDirectory users that access NSS volumes directly through NCP (the Novell Client™) are 
not required to be LUM-enabled. 


The exception is that if the Salvage feature is used, information on who deleted a file is not 
tracked unless the user is LUM-enabled. If a non-enabled user deletes a file, Salvage reports 
that the file was deleted by the server. 


Additionally, if any other file access protocol, such as Samba/CIFS, is used to access NSS 
through the virtual file system layer that makes NSS appear to be a POSIX-compliant file 
system, then the users must be LUM-enabled. 


Services That Do Not Require LUM-enabled Access 


The following end user services do not require LUM-enabled access: 


* 


* 


* 


IFolder 3.7 
iPrint 
NCP Client to an NCP Volume 


NCP Client to an NSS Volume (except deleter tracking for Salvage operations as noted in 
“Services That Do Not Require LUM-Enabled Access But Have Some LUM Requirements” on 
page 158) 
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* Novell AFP 
* Novell CIFS 


* QuickFinder™ 


LUM-Enabling Does Not Provide Global Access to ALL OES 2 Linux Servers 


As you plan to LUM-enable users for access to the services that require it, keep in mind that each 
OES 2 Linux server being accessed must be associated with a LUM-enabled group that the 
accessing users belong to. 


In other words, it is not sufficient to LUM-enable users for access to a single OES 2 Linux server if 
they need access to multiple servers. An association between the LUM-enabled groups that the users 
belong to and the eDirectory UNIX Workstation object associated with the server must be formed by 
using iManager for each server the users need access to. This can be accomplished for multiple 
servers by using the process described in “Enabling Users to Access Multiple OES 2 Linux Servers” 
on page 160. 


For more information on LUM, see the OES 2 SP2: Novell Linux User Management Technology 
Guide. 


15.2.2 Planning 


The following sections summarize LUM planning considerations. 


* "eDirectory Admin User Is Automatically Enabled for Linux Access" on page 159 
* "Planning Which Users to Enable for Access" on page 159 
* "Be Aware of System-Created Users and Groups" on page 159 


eDirectory Admin User Is Automatically Enabled for Linux Access 


When you install Linux User Management on an OES 2 Linux server, the Admin User object that 
installs LUM is automatically enabled for eDirectory LDAP authentication to the server. 


Planning Which Users to Enable for Access 


You need to identify the eDirectory users (and groups) who need access to services on OES 2 Linux 
servers that require LUM-enabled users. 


This can be easily determined by doing the following: 


1. Review the information in “Services in OES 2 Linux That Require LUM-Enabled Access" on 
page 156. 
2. Identify the servers that will run the services mentioned. 


3. On your planning sheets, note the users and groups that you need to enable and the servers you 
need to enable them to access. 


Be Aware of System-Created Users and Groups 


You should also be aware of the system-created users and groups that are LUM-enabled when NSS 
is installed. For more information, see Appendix I, “System User and Group Management in OES 2 
SP1,” on page 263. 
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15.2.3 Coexistence and Migration 


For coexistence and migration information, see “Understanding the Need for Linux Enabling Users” 
in the Novell Server Consolidation and Migration Toolkit Administration Guide. 


15.2.4 LUM Implementation Suggestions 


The following sections summarize LUM implementation considerations. 


* 


"About Enabling eDirectory Users for Linux Access" on page 160 

"*UNIX Workstation" and “Linux Workstation" Are the Same Thing" on page 160 
"Enabling Users to Access Multiple OES 2 Linux Servers" on page 160 

"Enabling eDirectory Groups for Linux Access" on page 161 


"Enabling eDirectory Users for Linux Access" on page 161 


About Enabling eDirectory Users for Linux Access 


You can enable eDirectory users for Linux User Management by using either iManager 2.7 or the 
nambulkadd command. 


* 


iManager: You can enable existing eDirectory users for Linux access by using the Linux User 
Management tasks in iManager. 


You can enable multiple users in the same operation as long as they can be assigned to the same 
primary LUM-enabled group. The enabling process lets you associate the group with one or 
more OES 2 Linux servers or Linux workstations. For more information, see ^Enabling Users 
to Access Multiple OES 2 Linux Servers" on page 160. 


Samba users are also enabled for Linux access as part of the Samba-enabling process. 


nambulkadd: If you have eDirectory users and groups that need to be enabled for Linux 
access, you can use the nambulkadd command to modify multiple objects simultaneously. For 
more information, see the OES 2 SP2: Novell Linux User Management Technology Guide. 


“UNIX Workstation” and “Linux Workstation" Are the Same Thing 


When you use iManager to manage OES 2 Linux access, you might notice some inconsistencies in 
naming. 


When OES 2 Linux servers are created, a “UNIX Workstation - server name" object is created in 
eDirectory, where server name is the DNS name of the OES 2 Linux server. In some places the 
iManager help refers to these server objects as “Linux Workstation" objects. 


Both "UNIX Workstation" and *Linux Workstation" refer to the same eDirectory objects. 


Enabling Users to Access Multiple OES 2 Linux Servers 





IMPORTANT: Users gain server access through their LUM-enabled group assignment rather than 
through a direct assignment to the UNIX Workstation objects themselves. 
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You can enable users for access to multiple OES 2 Linux servers by associating the LUM-enabled 
groups to which the users belong with the UNIX Workstation objects you want users to have access 
to. 


Enabling eDirectory Groups for Linux Access 
There are two methods for enabling eDirectory groups for Linux access: 


* "Using iManager” on page 161 
* "Using LUM Utilities at the Command Prompt" on page 161 


Using iManager 


The following steps assume that the eDirectory Group objects already exist and that any User 
objects you want to enable for Linux also exist and have been assigned to the groups. 

1 Login to iManager as the eDirectory Admin user or equivalent. 

2 Click Linux User Management > Enable Groups for Linux. 

3 Browse to and select one or more Group objects, then click OK. 

4 


If you want all users assigned to the group to be enabled for Linux, make sure the Linux-Enable 
All Users in These Groups option is selected. 


Click Next twice. 


oa 


6 Browse to and select one or more UNIX Workstation (OES 2 Linux server) objects, then click 
OK. 


7 Click Next, click Finish, then click OK. 


Using LUM Utilities at the Command Prompt 


Novell Linux User Management includes utilities for creating new LUM-enabled groups, and for 
enabling existing eDirectory groups for Linux access. 


* The nambulkadd utility lets you use a text editor to create a list of groups you want enabled for 
Linux access. For more information, see “nambulkadd” in the OES 2 SP2: Novell Linux User 
Management Technology Guide. 


IMPORTANT: Be sure to include a blank line at the end of each text file. Otherwise, the last 
line of the file won't be processed properly. 





* The namgroupadd utility lets you create a new LUM-enabled group or enable an existing 
eDirectory group for Linux access. For more information, see *namgroupadd" in the OES 2 
SP2: Novell Linux User Management Technology Guide. 


Enabling eDirectory Users for Linux Access 
There are two methods for enabling eDirectory users for Linux access: 


* "Using iManager” on page 162 
* "Using LUM Utilities at the Command Prompt" on page 162 
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Using iManager 

The following steps assume that the eDirectory User objects already exist. 
Log in to iManager as the eDirectory Admin user or equivalent. 
Click Linux User Management > Enable Users for Linux. 

Browse to and select one or more User objects, then click OK. 

Click Next. 


As indicated, you can do the following: 


a Fk WN = 


¢ Select and enable an existing eDirectory group for Linux. 
¢ Select an eDirectory group that is already enabled for Linux. 
* Specify the name and context of a new eDirectory group to create and enable for Linux. 
Select the option that matches your requirements. 
6 Click Next. 


Browse to and select one or more UNIX Workstation (OES 2 Linux server) objects, then click 
OK. 


8 Click Next, click Finish, then click OK. 


Using LUM Utilities at the Command Prompt 


Novell Linux User Management includes utilities for creating new LUM-enabled users, and for 
enabling existing eDirectory users for Linux access. 


¢ The nambulkadd utility lets you use a text editor to create a list of users you want enabled for 
Linux access. For more information, see “nambulkadd” in the OES 2 SP2: Novell Linux User 
Management Technology Guide. 





IMPORTANT: Be sure to include a blank line at the end of each text file. Otherwise, the last 
line of the file won’t be processed properly. 


* The namuseradd utility lets you create a single LUM-enabled user or enable an existing 
eDirectory user for Linux access. For more information, see “namuseradd” in the OES 2 SP2: 
Novell Linux User Management Technology Guide. 


15.3 Identity Management Services 


Providing network users with a network identity is a fundamental expectation for networking, but it 
can also become confusing when users need to track multiple identities to use network services. 
When you add the traditional POSIX users found on Linux systems to the mix, the picture becomes 
even more complex. 


The identity management services provided by Novell Open Enterprise Server (OES) leverage 
Novell eDirectory to simplify and customize identity management to fit your needs: 


* |f you currently store and manage all your users and groups in eDirectory, you can continue to 
do so. 
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¢ Ifyou use Novell Client software to provide network file and print services, you can now 
provide seamless file and print access to OES 2 Linux servers by using the NCP server for 
Linux and iPrint services. For more information, see Section 17.6, “NCP Implementation and 
Maintenance,” on page 210 and Chapter 18, “Print Services,” on page 217. 


* |f you want eDirectory users to have access to OES 2 Linux services that require POSIX 
authentication, you can enable the users for Linux access. For more information, see 
Section 15.2, “Linux User Management: Access to Linux for eDirectory Users,” on page 153. 


¢ Ifyou need to store and manage users in multiple directories, you can greatly strengthen your 
organization’s security and dramatically decrease your identity management costs by deploying 
Novell Identity Manager. For more information, see Section 15.4, “Using the Identity Manager 
3.5 Bundle Edition,” on page 163. 


15.4 Using the Identity Manager 3.5 Bundle 
Edition 


Novell Identity Manager is a data-sharing solution that leverages the Identity Vault to synchronize, 
transform, and distribute information across applications, databases, and directories. 


The Identity Manager Bundle Edition provides licensed synchronization of information (including 
passwords) held in NT Domains, Active Directory Domains, and eDirectory systems. When data 
from one system changes, Identity Manager detects and propagates these changes to other connected 
systems based on the business policies you define. 


In this document: 


* Section 15.4.1, "What Am I Entitled to Use?," on page 163 

* Section 15.4.2, "System Requirements," on page 164 

* Section 15.4.3, "Installation Considerations," on page 164 

* Section 15.4.4, “Getting Started,” on page 164 

* Section 15.4.5, "Activating the Bundle Edition," on page 164 

* Section 15.4.6, “Frequently Asked Questions about Activation,” on page 165 


15.4.1 What Am I Entitled to Use? 


The Bundle Edition allows you to use the Identity Manager engine and the following Identity 
Manager drivers: 

¢ Identity Manager Driver for eDirectory 

¢ Identity Manager Driver for Active Directory 

¢ Identity Manager Driver for NT 
Other Identity Manager Integration Modules (drivers) are included in the software distribution. You 


can install and use these additional Integration Modules for 90 days, at which time you must 
purchase Novell Identity Manager and the Integration Modules you want to use. 


The User Application and the service drivers (Loopback, Manual Task, and Entitlements) are not 
included as part of the license agreement for the Bundle Edition. In order to use these Identity 
Manager components, you must purchase Identity Manager. 
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15.4.2 System Requirements 


For the latest Identity Manager system requirements, see the /dentity Manager Installation Guide 
(http://www.novell.com/documentation/idm35/install/data/front.html). 


The Bundle Edition does not include Solaris or AIX support. If you want to run the Metadirectory 
engine or Integration Modules on these platforms, you must purchase Identity Manager. 


15.4.3 Installation Considerations 


Novell Identity Manager Bundle Edition contains components that can be installed within your 
environment on multiple systems and platforms. Depending on your system configuration, you 
might need to run the installation program several times to install Identity Manager components on 
the appropriate systems. 


In order for the product to be activated, you must install Open Enterprise Server before installing the 
Identity Manager Bundle Edition. For more information on activation issues, see “Activating the 
Bundle Edition” on page 164. 


15.4.4 Getting Started 


The following sections from the Novell Identity Manager Administration Guide will help you plan, 
install, and configure your Identity Manager Bundle Edition: 
+ "Overview" (http://www.novell.com/documentation/idm35/install/data/alxkrnf.html) 


* “Planning Your Implementation" (http://www.novell.com/documentation/idm35/install/data/ 
anhomxn.html) 


* “Installing Identity Manager" (http://www.novell.com/documentation/idm35/install/data/ 
a7c9ie0.html) 

* “Installing Active Directory, NT, and eDirectory Drivers" (http://www.novell.com/ 
documentation/idm35drivers/index.html) 


* "Setting Up a Connected System" (http://www.novell.com/documentation/idm35/admin/data/ 
bs35odr.html) 


* “Password Synchronization across Connected Systems" (http://www.novell.com/ 
documentation/idm35/admin/data/an4bz0u.html) 


+ “Logging and Reporting” (http://www.novell.com/documentation/idm35/idm_log/data/ 
bookinfo.html) 


For information about customizing your implementation: 


¢ Policy Builder and Driver Customization Guide (http://www.novell.com/documentation/ 
idm35/policy/data/bookinfo.html) 


15.4.5 Activating the Bundle Edition 


If you choose to purchase additional Identity Manager Integration Modules, you need to install the 
activation credential for those Integration Modules and also the credential for Novell Identity 
Manager. See Activating Identity Manager Products Using a Credential (http://www.novell.com/ 
documentation/idm35/install/data/brph5hb.html) for more information on activating other Identity 
Manager products. 
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In order to use the Bundle Edition, you must obtain and install an activation credential. Use the 
following instructions to complete the Bundle Edition activation tasks. 


1 


Browse to the Identity Manager Bundle Edition Registration (http://download.novell.com/ 
delivery/reg/idm bundled.jsp) Web site. 


2 Enter your OES activation code, then click Submit. 


"o oc A 


eo 


Do one of the following: 
* Save the Product Activation Credential file. 
or 


* Open the Product Activation Credential file, then copy the contents of the Product 
Activation Credential to your clipboard. Carefully copy the contents, and make sure that 
no extra lines or spaces are included. You should begin copying from the first dash (-) of 
the credential (----BEGIN PRODUCT ACTIVATION CREDENTIAL) through the last 
dash (-) of the credential (END PRODUCT ACTIVATION CREDENTIAL-----). 


Open iManager. 
Choose Identity Manager > Identity Manager Overview. 
Select the driver set or browse to a driver set, then click Next. 


On the Identity Manager Overview page, locate the driver set, click the red Activation required 
by link, then click Install Activation. 


Select the driver set where you want to activate an Identity Manager component. 


9 Do one of the following: 


10 


* Specify where you saved the Identity Manager Activation Credential, then click Next. 
or 


* Paste the contents of the Identity Manager Activation Credential into the text area, then 
click Next. 


Click Finish. 


15.4.6 Frequently Asked Questions about Activation 


* 


* 


“Do I need to Install Identity Manager on a specific server?" on page 166 


“T installed the Bundle Edition on Linux or NetWare, but it’s not activated. Why is this?" on 
page 166 


"Can I run Identity Manager on a Windows Server?" on page 166 

"Can I run Identity Manager on a Solaris or AIX Server?" on page 166 

“My drivers stopped working. What happened?" on page 166 

“I purchased an additional Integration Module. Why doesn't it work?" on page 166 


“If I purchase a license for Novell Identity Manager and a license for an additional Integration 
Module, do I need to re-install the software?" on page 166 


“How do I know what's activated?" on page 167 
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Do I need to Install Identity Manager on a specific server? 


Yes. As a Bundle Edition user, you must install Identity Manager on the server where you installed 
Open Enterprise Server. In order for activation to work properly, you must install Identity Manager 
on Linux or NetWare, and create a driver set on that server. 


l installed the Bundle Edition on Linux or NetWare, but it's not activated. Why is 
this? 


You must install the Bundle Edition on the server where OES exists. If you install it on a non-OES 
server, the Bundle Edition cannot activate. 


Can | run Identity Manager on a Windows Server? 


Not with the Bundle Edition. However, you can still synchronize data held on a Windows server by 
using the Identity Manager Remote Loader service. The Remote Loader enables synchronization 
between the Metadirectory Engine (on your Linux or NetWare server) and a remote driver (on the 
Windows server.) See Setting Up a Connected System (http://www.novell.com/documentation/ 
idm35/admin/data/bs35odr.html) for more information. 


In order to run Identity Manager on a Windows server, you need to purchase Novell Identity 
Manager. 


Can | run Identity Manager on a Solaris or AIX Server? 


Not with the Bundle Edition. However, you can still synchronize data held on these platforms by 
using the Identity Manager Remote Loader service. The Remote Loader enables synchronization 
between the Metadirectory Engine and a remote driver (on the Solaris or AIX server.) See Setting 
Up a Connected System (http://www.novell.com/documentation/idm35/admin/data/bs35odr.html) 
for more information. 


In order to run Identity Manager on Solaris or AIX, you need to purchase Novell Identity Manager. 


My drivers stopped working. What happened? 


You might have installed the Bundle Edition on a non-OES server. The Bundle Edition must be 
installed on your Linux or NetWare server where OES exists. If Identity Manager is installed on a 
non-OES platform, activation cannot work. After 90 days, your drivers will stop running if you 
haven't purchased Novell Identity Manager. 


| purchased an additional Integration Module. Why doesn't it work? 


With your OES purchase, you are entitled to use the Bundle Edition products. If you want to add 
new Integration Modules, you also need to purchase Novell Identity Manager. The Integration 
Module cannot activate until you purchase Novell Identity Manager. 


If | purchase a license for Novell Identity Manager and a license for an additional 
Integration Module, do I need to re-install the software? 


No, you just need to install the activation credentials associated with your purchase. 
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How do I know what's activated? 


For information about how to view currently activated products, see “Viewing Product Activations” 
(http://www.novell.com/documentation/idm35/install/data/agfhtax.html). 
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Access Control and 
Authentication 


Access Control and Authentication are the keys to: 


¢ Providing services for users. 


* Ensuring that the network is secure. 
This section discusses the following: 


* Section 16.1, “Controlling Access to Services,” on page 169 


* Section 16.2, "Authentication Services," on page 182 


16.1 Controlling Access to Services 


OES 2 supports a number of options for service access, including 


* Web browsers. 

* File managers and applications on Linux, Macintosh, and Windows workstations. 

* Novell Client!" software. 

* Personal digital assistants (PDAs) and other electronic devices that are enabled for Web access. 


You control which of these options can be used through the services you offer and the ways your 
configure those services. 


This section can help you understand access control at a high level so that you can plan, implement, 
and control access to services. More detail about the items discussed is contained in individual 
service guides. 


The topics that follow are: 


* Section 16.1.1, "Overview of Access Control," on page 169 

* Section 16.1.2, “Planning for Service Access,” on page 176 

* Section 16.1.3, *Coexistence and Migration of Access Services," on page 179 
* Section 16.1.4, "Access Implementation Suggestions," on page 180 


* Section 16.1.5, *Configuring and Administering Access to Services," on page 180 


16.1.1 Overview of Access Control 


The following sections present overviews of methods for accessing Open Enterprise Server 2 
services. 

* "Access to OES 2 Services" on page 170 

* "Access Control Options in OES 2" on page 171 

* “The Traditional Novell Access Control Model" on page 172 

* “NSS Access Control on OES Linux” on page 174 
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* “Novell Client (NCP File Services) Access" on page 175 
* “eDirectory User Access to OES 2 Linux Servers" on page 176 


Access to OES 2 Services 


Figure 16-1 illustrates the access methods supported by OES 2 services. Novell® eDirectory™ 
provides authentication to each service. 


Figure 16-1 Access Interfaces and the Services They Can Access 
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The interfaces available for each service are largely determined by the protocols supported by the 
service. 
* Browsers and personal digital assistants require support for the HTTP protocol. 


* Each workstation type has file access protocols associated with it. Linux uses NFS as its native 
protocol for file services access, Macintosh workstations communicate using AFP or CIFS, and 
Windows workstations use the CIFS protocol for file services. 


* Novell Client software for both Windows and Linux uses the NetWare® Core Protocol!" 
(NCP™) to provide the file services for which Novell is well known. 
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Understanding the protocol support for OES 2 services can help you begin to plan your OES 
implementation. For more information, see “Matching Protocols and Services to Check Access 


Requirements” on page 178. 


Access Control Options in OES 2 


Because OES 2 offers both traditional Novell access control and POSIX access control, you have a 
variety of approaches available to you, including combining the two models to serve various aspects 


of your network services. 


Table 16-1 provides links to documentation that discusses OES 2 access control features. 


Table 16-1 General File System Access Control 


Feature 


Access Control Lists (ACLs) on 
Linux 


To Understand 


How ACLs are supported on the 
most commonly used Linux 
POSIX file systems and let you 
assign file and directory 
permissions to users and groups 
who do not own the files or 
directories. 


See 


“Access Control Lists in Linux” 
(http:/Awww.novell.com/ 
documentation/sles10/ 
book_sle_reference/data/ 
cha_acls.html) in the SLES 10 
SP3: Installation and 
Administration Guide (http:// 
www.novell.com/documentation/ 
sles10/book_sle_reference/data/ 
book_sle_reference.html) 





Aligning NCP and POSIX access 
rights 


How to approximate the NCP (or 
NetWare) access control model 
on POSIX file systems. 


“Section 17.4, “Aligning NCP and 
POSIX File Access Rights,” on 
page 206” 





Directory and file attributes 


Directory and file attributes on 
OES 2 NetWare. 


“Directory and File Attributes for 
NSS Volumes or NetWare 
Traditional Volumes” in the NW 
6.5 SP8: File Systems 
Management Guide 





File system trustee rights 


File system trustee rights on 
NetWare (NSS and traditional 
volumes), including how NetWare 
determines effective file system 
trustee rights. 


“File-System Trustee Rights ” in 
the NW 6.5 SP8: File Systems 
Management Guide 





NetWare Connection Manager 


How the NetWare Connection 
Manager tracks active user 
connections and provides access 
permission information for NSS 
and Traditional volumes on 
NetWare. 


“The Connection Manager for 
NetWare” in the NW 6.5 SP8: File 
Systems Management Guide 





Novell Client and the NetWare 
Connection Manager 


How the Novell Client works with 
the Connection Manager to 
ensure that users have correct 
access rights to the file system. 


"Novell Client" in the NW 6.5 SP8: 
File Systems Management Guide 
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Feature 


NetWare trustee rights and 
directory and file attributes 


To Understand 


How to control who can see 
which files and what they can do 
with them. 


See 


“Understanding File System 
Access Control Using Trustees” 
in the NW 6.5 SP8: File Systems 
Management Guide 





POSIX file system rights and 
attributes on Linux 


How to configure file system 
attributes on OES 2 Linux 
servers. 


"Access Control Lists in Linux" 
(http://www.novell.com/ 
documentation/sles 10/ 

book sle reference/data/ 

cha acls.html) in the SLES 10 
SP3: Installation and 
Administration Guide (http:// 
www.novell.com/documentation/ 
sles10/book sle reference/data/ 
book sle reference.html) 





Rights to install applications on 
NetWare 


The access rights required to 
install applications on NetWare 
file systems. 


"Security Guidelines" in the NW 
6.5 SP8: File Systems 
Management Guide 





Security Equivalence in 
eDirectory 


The concept of Security 
Equivalence in eDirectory. 


The Traditional Novell Access Control Model 


"eDirectory Objects and Security 
Equivalence” in the NW 6.5 SP8: 
File Systems Management Guide 


NetWare is known for its rich access control. OES makes these controls available on Linux through 
NSS volume support. In addition, some of the controls are available on Linux POSIX file systems 

through NCP volume creation. NCP volumes are limited because Linux POSIX systems offer only a 
subset of the directory and file attributes that NSS offers. 


In the NetWare access control model, eDirectory objects, such as users and groups, are assigned File 
System Trustee Rights to directories and files on NSS and NCP volumes. These trustee rights 
determine what the user or group can do with a directory or file, provided that the directory or file 


attributes allow the action. 


This is illustrated in Figure 16-2. 
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Figure 16-2 Directory and File Access under the NetWare Access Control Model 
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Table 16-2 explains the effective access rights illustrated in Figure 16-2. 
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Table 16-2 Access Rights Explanation 


eDirectory File System Trustee 
Objects Rights 

eDirectory File system trustee 
objects (in rights govern access 
mostcases and usage by the 
users and eDirectory object 
groups) gain specified for the 
access to directory or file to 
the file which the rights are 
System granted. 

through 

eDirectory. Trustee rights are 


overridden by 
directory and file 
attributes. 


For example, even 
though Nancy has the 
Supervisor (all) 
trustee right at the 
directory (and, 
therefore, to the files it 
contains), she cannot 
delete File2 because it 
has the Read Only 
attribute set. 


Of course, Nancy 
could modify the file 
attributes so that File2 
could then be deleted. 


Directory and File 
Attributes 


Each directory and 
file has attributes 
associated with it. 
These attributes 
apply universally to 
all trustees 
regardless of the 
trustee rights an 
object might have. 


For example, a file 
that has the Read 
Only attribute is 
Read Only for all 
users. 


Attributes can be set 
by any trustee that 
has the Modify 
trustee right to the 
directory or file. 


NSS Access Control on OES Linux 


Directories and Files 


The possible actions by the eDirectory 
users and group shown in this example 
are as follows: 


* Nancy has the Supervisor trustee 
right at the directory level, meaning 
that she can perform any action not 
blocked by a directory or file 
attribute. 


The Di (Delete Inhibit) and Ri 
(Rename Inhibit) Attributes on 
Directory A prevent Nancy from 
deleting or renaming the directory 
unless she modifies the attributes 
first. The same principle applies to 
her ability to modify File2. 


* Because Joe is a member of the 
Reporters group, he can view file and 
directory names inside DirectoryA 
and also see the directory structure 
up to the root directory. 


Joe also has rights to open and read 
any files in DirectoryA and to execute 
any applications in DirectoryA. 


* Because Bert is a member of the 
Reporters group, he can view file and 
directory names inside DirectoryA 
and also see the directory structure 
up to the root directory. 


Bert also has rights to open and read 
File1 and to execute it if it's an 
application. 


And Bert has rights to grant any 
eDirectory user access to File1. 


* Because all three users are 
members of the Reporters group, 
they can grant any eDirectory user 
access to File2. 


Of course, for Nancy this is 
redundant because she has the 
Supervisor right at the directory level. 


Table 16-3 provides links to documentation that discusses the various NSS-specific access control 


features. 
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Table 16-3 Summary of NSS Access Control Documentation Links 


Feature To Understand See 

Independent Mode vs. NetWare _ The difference between "Access Control for NSS on 

Mode Independent Mode access and Linux" in the NW 6.5 SP8: File 
NetWare Mode access. Systems Management Guide 

This applies only to Linux 

servers. 

NetWare directory and file How NSS file attributes are "Displaying Key NSS Directory 

attributes on NSS volumes on reflected in Linux directory and and File Attributes as Linux 

OES 2 Linux file permissions viewable through POSIX Permissions” in the NW 
POSIX. 6.5 SP8: File Systems 

This is only about what is Management Guide 


displayed. POSIX permissions 
are not used for access control to 
NSS volumes. 


Novell Client (NCP File Services) Access 


If you have not already determined whether to use the Novell Client on your network, we 
recommend that you consider the following information: 

* "About the Novell Client" on page 175 

* "[s the Novell Client Right for Your Network?" on page 175 


* "Differences between Linux and Windows" on page 176 


About the Novell Client 


The Novell Client extends the capabilities of Windows and Linux desktops with access to NetWare 
and OES 2 Linux servers. 


After installing Novell Client software, users can enjoy the full range of Novell services, such as 


* Authentication via Novell eDirectory 

* Network browsing and service resolution 
* Secure and reliable file system access 

* Support for industry-standard protocols 


The Novell Client supports the traditional Novell protocols (NDAP, NCP, and RSA) and 
interoperates with open protocols (LDAP, CIFS, and NFS). 


Is the Novell Client Right for Your Network? 


Although Novell offers services that don't require Novell Client, (such as NetStorage, Novell 
iFolder? 3.7, and IPrint), many network administrators continue to prefer the Novell Client as the 
access choice for their network users for the following reasons: 


* They prefer eDirectory authentication to LDAP authentication because they believe it is more 
secure. 


* They prefer the NetWare Core Protocol (NCP) over the Microsoft CIFS protocol because they 
believe that CIFS 1s more vulnerable to the propagation of viruses on the network. 
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Conversely, other network administrators are equally adamant that their users function better 
without the added overhead of running an NCP client on each workstation. 


We can’t determine what is best for your network, but we do provide you with viable choices. 


Differences between Linux and Windows 


There are some differences between the Linux and Windows clients. These are documented in 
“Understanding the Novell Client for Linux” in the Novell Client 2.0 SP2 for Linux Administration 
Guide. 


eDirectory User Access to OES 2 Linux Servers 


Some services that run on OES 2 Linux servers require that the users accessing them be (or, at least, 
appear to the Linux system to be) standard Linux users with Linux user credentials, such as a user 
ID (UID) and primary group ID (GID). 


So that eDirectory users can access these services, Novell provides the Linux User Management 
(LUM) technology. The impact of this on you as the network administrator is that these users and 
groups must be enabled for eDirectory LDAP authentication to the local server. For more 
information, see “Linux User Management: Access to Linux for eDirectory Users” on page 153. 


16.1.2 Planning for Service Access 


After you understand the access options available to your network users, you can decide which will 
work best on your network. 


Planning tips for network services are contained in the following sections: 


* "Planning File Service Access” on page 176 
* "Planning Print Service Access" on page 177 


* "Matching Protocols and Services to Check Access Requirements" on page 178 


Planning File Service Access 


As you plan which file services to provide, be aware of the file service/volume and feature support 
limitations outlined in the following sections. 


* "Service Access to Volume Type Limitations" on page 176 


* "Feature Support" on page 177 


Service Access to Volume Type Limitations 


Supported combinations are outlined in Table 16-4. 


Table 16-4 Service Access to Volume Types 


Linux POSIX NSS Volumes on NetWare NSS Volumes on 
File Service h Traditional 
Volumes Linux NetWare 
Volumes 
AFP No Yes-Novell AFP No Yes-NFAP 
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NetWare 

















. . Linux POSIX NSS Volumes on iis NSS Volumes on 
File Service Fi Traditional 
Volumes Linux NetWare 
Volumes 
CIFS Yes-Novell CIFS Yes-Novell CIFS No Yes-NFAP 
Novell Samba Novell Samba 
NetStorage Yes Yes Yes Yes 
NetWare Core Protocol Yes Yes Yes Yes 
(NCP) 
NFS Yes Yes-NFSv3 No Yes-NFAP 
Novell iFolder 2.1x No No No Yes 
Novell iFolder 3.7 Yes Yes No No 


Details about the file systems supported by each file service are explained in the documentation for 


each service. 


Be aware that file services support different sets of access protocols. A summary of the protocols 
available for access to the various OES file services is presented in “Matching Protocols and 
Services to Check Access Requirements” on page 178. 


Feature Support 


Table 16-5 Features Supported on Each Volume Type 




















Linux POSIX NSS Volumes on NetWare NSS Volumes on 
Feature $ Traditional 
Volumes Linux NetWare 
Volumes 
Directory quotas No Yes Yes Yes 
Login scripts Yes (if also Yes Yes Yes 
defined as an 
NCP volume) 
Mapped drives Yes (if also Yes Yes Yes 
defined as an 
NCP volume) 
Novell directory and file No Yes Yes Yes 
attributes 
Purge/Salvage No Yes Yes Yes 
Trustee rights Yes (if also Yes Yes Yes 
defined as an 
NCP volume) 
User space quotas No Yes Yes Yes 


Planning Print Service Access 


Novell iPrint has access control features that let you specify the access that each eDirectory User, 
Group, or container object has to your printing resources. 


Access Control and Authentication 


177 


You can also use iPrint to set up print services that don’t require authentication. 





NOTE: Access control for printers is supported only on the Windows iPrint Client. 





For more information on access control and iPrint, see the following: 


+ "Setting Access Control for Your Print System” in the OES 2 SP2: iPrint for Linux 
Administration Guide 


* "Setting Access Control for Your Print System” in the NW 6.5 SP6: iPrint Administration 
Guide 


Matching Protocols and Services to Check Access Requirements 


Figure 16-3 illustrates the access interfaces available to users in OES and the services that each 
interface can connect to. It also shows the protocols that connect access interfaces with network 
services. 


To use this for planning: 


1. Review the different access interfaces in the left column. 
2. In the middle column, review the protocols each interface supports. 


3. In the right column, view the services available to the interfaces via the protocols. 
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Figure 16-3 Access Interfaces and Services, and the Protocols That Connect Them 
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iPrint 
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16.1.3 Coexistence and Migration of Access Services 


Because NetWare Core Protocol (NCP) is now available on Linux, your Novell Client users can 
attach to OES 2 Linux servers as easily as they have been able to attach to NetWare servers. In fact, 


they probably won’t notice any changes. 


NCP Server for Linux enables support for login scripts, mapping drives to OES 2 Linux servers, and 
other services commonly associated with Novell Client access. This means that Windows users with 
the Novell Client installed can now be seamlessly transitioned to file services on OES 2 Linux. And 
with the Novell Client for Linux, Windows users can be moved to SUSE® Linux Enterprise Desktop 


with no disruption in NCP file services. 


For more information, see the OES 2 SP2: NCP Server for Linux Administration Guide. 
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16.1.4 Access Implementation Suggestions 


After you plan and install OES 2 services, be sure to provide clear access instructions to your 
network users. For a summary of access methods, see Appendix E, “Quick Reference to OES 2 User 
Services,” on page 253. 


16.1.5 Configuring and Administering Access to Services 


The following sections discuss administering access to services. 


* "Password Management" on page 180 
* "Linux (POSIX) File System Access Rights" on page 180 
* “NSS (and NetWare) File and Directory Trustee Management" on page 181 


Password Management 


Many network administrators let users administer their own passwords. For more information on 
password self management, see “Password Self-Service" in the Novell Password Management 3.2 
Administration Guide. 


Linux (POSIX) File System Access Rights 


Access control to Linux POSIX file systems is controlled through POSIX file system access rights 
or attributes associated with directories and files. In general, the directories and files can be accessed 
by three POSIX entities: 

* The user who owns the directory or file 

* The group who owns the directory or file 

* All other users defined on the system 


These users and the affected group are each assigned (or not assigned) a combination of three 
attributes for each directory and file: 


Table 16-6 Linux Access Rights 


Attribute Effect on Directory when Assigned Effect on File when Assigned 

Read Lets the user or group view the Lets the user or group open and read the 
directory's contents. file. 

Write Lets the user or group create or delete Lets the user or group modify the file. 


files and subdirectories in the directory. 


Execute Lets the user or group access the Lets the user or group run the file as a 
directory by using the cd command. program. 


For more information, see *Configuring File System Trustees, Trustee Rights, Inherited Rights 
Filters, and Attributes" in the NW 6.5 SP6: File Systems Management Guide. 
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NSS (and NetWare) File and Directory Trustee Management 


The NW 6.5 SP6: File Systems Management Guide contains a thorough discussion of file and 
directory trustee management in its “Configuring File System Trustees, Trustee Rights, Inherited 
Rights Filters, and Attributes” section. 


The following sections present brief information about managing trustees on NSS volumes. 


* "Using NetStorage to Change File and Directory Attributes and Trustees" on page 181 


* "Using the Novell Client to Change File and Directory Attributes and Trustee Rights" on 
page 181 


* "Using iManager 2.7 to Change File and Directory Attributes and Trustee Rights" on page 181 
* "Using the Linux Command Prompt to Change File Attributes" on page 181 





* "Using the Linux Command Prompt to Change Trustee Rights" on page 181 


Using NetStorage to Change File and Directory Attributes and Trustees 


You can use the NetStorage Web browser interface to change attributes and trustees for directories 
and files on NSS volumes, but you can't change them by using a WebDAV connection to 
NetStorage. 


You cannot change attributes or trustees on NetWare Traditional volumes by using NetStorage. 


Using the Novell Client to Change File and Directory Attributes and Trustee Rights 


You can use the Novell Client to change NSS file and directory attributes and to grant trustee rights 
to an NSS volume on an OES 2 Linux server. For more information, see “NetWare File Security” in 
the Novell Client 4.91 SP5 for Windows XP/2003 Installation and Administration Guide and 
“Managing File Security" in the Novell Client 2.0 SP2 for Linux Administration Guide. 


Using iManager 2.7 to Change File and Directory Attributes and Trustee Rights 


You can use the iManager 2.7 Files and Folders plug-in to manage directories and files on NCP and 
NSS volumes. For more information, see the plug-in help. 


Using the Linux Command Prompt to Change File Attributes 
Use the attrib command to change file and directory attributes on an NSS volume. 


The attrib command is also documented in “Attributes Utility for Linux” in the NW 6.5 SP8: File 
Systems Management Guide. 


You can also enter the following command at the command prompt: 


attrib --help 


Using the Linux Command Prompt to Change Trustee Rights 
To grant NSS trustee rights to an NSS volume, enter the following command: 
rights -f /full/directory/path -r rights mask trustee full.object.context 


where /full/directory/path is the path to the target directory on the NSS volume, rights mask is the 
list of NSS rights, and full.object.context is the object (User or Group) in its full eDirectory context 
including the tree name. 
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For example, you might enter the following: 





rights -f /data/groupstuff -r rwfc trustee mygroup.testing.example tr 
For a complete list of command options, enter rights at the command prompt. 


The rights command is also documented in “Trustee Rights Utility for Linux" in the NW 6.5 SP8: 
File Systems Management Guide. 


16.2 Authentication Services 


This section briefly discusses the following topics: 


* Section 16.2.1, "Overview of Authentication Services," on page 182 
* Section 16.22, “Planning for Authentication," on page 185 
* Section 16.2.3, “Authentication Coexistence and Migration," on page 185 


* Section 16.2.4, *Configuring and Administering Authentication," on page 185 


16.2.1 Overview of Authentication Services 


This section provides specific overview information for the following key OES components: 


* "Netldentity Agent" on page 182 
* "Novell Modular Authentication Services (NMAS)" on page 183 
* "Password Support in OES 2" on page 183 


For more authentication topics, see “Access, Authenticate, Log in" in the OES online 
documentation. 


Netldentity Agent 


In OES 2, the NetIdentity Agent works with Novell eDirectory authentication to provide 
background authentication to Windows Web-based applications that require eDirectory 
authentication through a secure identity “wallet” on the workstation. Applications access the 
eDirectory credentials without prompting users for a username and password. 


The NetIdentity Agent supports applications running on OES 2 server platforms as follows: 


* OES 2 Linux: NetStorage 
* OES 2 NetWare: NetStorage and iPrint (if authentication is required) 


NetIdentity Agent browser authentication is supported only by Windows Internet Explorer. 


The Novell Client provides authentication credentials to NetIdentity, but it does not obtain 
authentication credentials from NetIdentity because it is not a Web-based application. 


NetIdentity Agent requires 


* XTier (NetStorage) on the OES 2 server presented in the URL for the Web-based applications. 
+ The NetIdentity agent installed on the workstations. 


For more information on using the NetIdentity agent, see the Net/dentity Administration Guide for 
NetWare 6.5. 
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Novell Modular Authentication Services (NMAS) 


Novell Modular Authentication Services (NMAS™) lets you protect information on your network 
by providing various authentication methods to Novell eDirectory on NetWare, Windows, and 
UNIX networks. 


These login methods are based on three login factors: 


* Password 
* Physical device or token 


* Biometric authentication 
For example: 


+ You can have users log in through a password, a fingerprint scan, a token, a smart card, a 
certificate, a proximity card, etc. 

* Youcan have users log in through a combination of methods to provide a higher level of 
security. 


Some login methods require additional hardware and software. You must have all of the necessary 
hardware and software for the methods to be used. 


NMAS software consists of the following: 


* NMAS server components: Installed as part of OES 2. 


* The NMAS Client: Required on each Windows workstation that will be authenticating using 
NMAS. 


Support for Third-Party Authentication Methods 
Novell Client distributions include a number of NMAS login methods. 


Other third-party methods are available for download. For information on the available third-party 
login methods, see the NMAS Partner’s Web site (http://www.novell.com/products/nmas/ 
partners communities.html). Each method has a readme.txt file or a readme . pdf file that 
includes specific installation and configuration instructions. 


More Information 


For more information on how to use NMAS, see the Novell Modular Authentication Services 3.3 
Administration Guide. 


Password Support in OES 2 


In the past, administrators have needed to manage multiple passwords (simple password, NDS? 
passwords, Samba passwords) because of password differences. Administrators have also needed to 
deal with keeping the passwords synchronized. 


In OES you have the choice of retaining your current password maintenance methods or deploying 
Universal Password to simplify password management. For more information, see the Novell 
Password Management 3.2 Administration Guide. 
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All Novell products and services are being developed to work with extended character (UTF-8 
encoded) passwords. For a current list of products and services that work with extended characters, 
see Novell TID 3065822 (http://www.novell.com/support/ 

search.do?cmd-displayKC &docType=kc&externalld=3065822&sliceld=1&docTypeID=DT_TID_ 
1 1&dialogID-77556590&stateId—09020096020777560425). 


The password types supported in eDirectory are summarized in Table 16-7. 
Table 16-7 eDirectory Password Types 


Password Type Description 


NDS The NDS password is stored in a hash form that is nonreversible in eDirectory. Only 
the NDS system can make use of this password, and it cannot be converted into any 
other form for use by any other system. 





Novell AFP and In OES 2, AFP and CIFS users have Universal Password policies assigned by 

Novell CIFS default. The same policy can be used for both services, as shown in "Creating a UP 
Policy to Support Both AFP and CIFS" in the OES 2 SP2: Lab Guide for Linux and 
Virtualized NetWare. More information about password policy planning is available in 
"Coordinating Password Policies Among Multiple File Services" in the OES 1 
Readme. 





Samba In OES 2, Samba users have a Universal Password policy assigned by default. 


OES 2 also supports the Samba hash password if desired. However, you must 
choose to not deploy Universal Password if you want to use the Samba hash 
password. Choosing the Samba password requires that users always remember to 
synchronize it when changing their eDirectory password. 


For more information, see "Samba Passwords” in the OES2 SP2: Samba 
Administration Guide. 





Simple The simple password provides a reversible value stored in an attribute on the User 
object in eDirectory. NMAS securely stores a clear-text value of the password so that 
it can use it against any type of authentication algorithm. To ensure that this value is 
secure, NMAS uses either a DES key or a triple DES key (depending on the strength 
of the Secure Domain Key) to encrypt the data in the NMAS Secret and 
Configuration Store. 


The simple password was originally implemented to allow administrators to import 
users and hashed passwords from other LDAP directories such as Active Directory 
and iPlanet". 


The limitations of the simple password are that no password policy (minimum length, 
expiration, etc.) is enforced. Also, by default, users do not have rights to change their 
own simple passwords. 
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Password Type Description 


Universal Universal Password (UP) enforces a uniform password policy across multiple 
authentication systems by creating a password that can be used by all protocols and 
authentication methods. 


Universal Password is managed in iManager by the Secure Password Manager 
(SPM), a component of the NMAS module installed on OES 2 servers. All password 
restrictions and policies (expiration, minimum length, etc.) are supported. 


All the existing management tools that run on clients with the UP libraries 
automatically work with the Universal Password. 


Universal Password is not automatically enabled unless you install Novell AFP, 
Novell CIFS, Domain Services for Windows, or Novell Samba on an OES 2 Linux 
server. You can optionally choose to have the Samba hash password stored 
separately. This requires, however, that users always synchronize the Samba 
password when changing their eDirectory password. 


The Novell Client supports the Universal Password. It also supports the NDS 
password for older systems in the network. The Novell Client automatically upgrades 
to use Universal Password when UP is deployed. 


For more information, see “Deploying Universal Password” in the Novell Password 
Management 3.2 Administration Guide. 


16.2.2 Planning for Authentication 


For planning topics, see the “Access, Authenticate, Log in” in the OES online documentation. 


16.2.3 Authentication Coexistence and Migration 


For authentication and security coexistence and migration information, see “Chapter 21, “Security,” 
on page 227 and Chapter 22, “Certificate Management,” on page 233” in this guide. 


16.2.4 Configuring and Administering Authentication 


For a list of configuration and administration topics, see “Access, Authenticate, Log in” in the OES 
online documentation. 
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File Services 


The file services in Open Enterprise Server 2 let you provide Web-based and network-based file 
services to your network users. 


This section contains the following information: 


* 


* 


Section 17.1, “Overview of File Services," on page 187 

Section 17.2, *Planning for File Services," on page 200 

Section 17.3, “Coexistence and Migration of File Services,” on page 204 

Section 17.4, “Aligning NCP and POSIX File Access Rights,” on page 206 

Section 17.5, *Native File Access Protocols Implementation and Maintenance," on page 209 
Section 17.6, *NCP Implementation and Maintenance," on page 210 

Section 17.7, *NetStorage Implementation and Maintenance," on page 211 


Section 17.8, “Novell AFP Implementation and Maintenance,” on page 214 





Section 17.9, *Novell CIFS Implementation and Maintenance," on page 214 





Section 17.10, *Novell iFolder 3.7 Implementation and Maintenance," on page 215 


Section 17.11, “Samba Implementation and Maintenance," on page 216 





NOTE: Novell? iFolder? 2 is available only on NetWare®. 


There are no new features in iFolder 2, and most references to it have been removed from the OES 2 
documentation. However, the iFolder 2 documentation on the OES 1 Online Documentation Web 
site (http://www.novell.com/documentation/oes/file-services.html#if2) still applies. 





17.1 Overview of File Services 


The file service components in OES include the following: 


* 


* 


FTP Services (page 188): Lets users securely transfer files to and from OES 2 servers. 


Native File Access Protocols (page 188): Lets Linux, Macintosh, UNIX, and Windows users 
access and store files on OES 2 NetWare servers through their native file access methods. 


NetWare Core Protocol (page 189): Provides NetWare Core Protocol™ (NCP™) access to 
NetWare servers and to NCP volumes (including NSS volumes) that you define on OES 2 
Linux server partitions. 








NetStorage (page 190): Provides network and Web access to various Linux, NetWare, and 
Windows file services. 


The NetStorage server doesn't actually store files and folders. Rather, it provides access to 
other file services on OES 2 Linux and NetWare servers that support the native TCP/IP 
protocol. 


Novell AFP (page 195): Provides native Macintosh access to files stored on an NSS volume on 
an OES 2 Linux server. 
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* Novell CIFS (page 196): Provides native Windows (CIFS and HTTP-WebDAV) access to files 
stored on an NSS volume on an OES 2 Linux server. 


* Novell iFolder 3.7 (page 197): Provides a Web-based and network-based repository (Novell 
iFolder server) that stores master copies of locally accessible files on the OES 2 server. 


* Novell Samba (page 199): Provides Windows (CIFS and HTTP-WebDAV) access to files 
stored on an OES 2 Linux server's file system. 


The file service components in OES are generally compatible. However you cannot run Novell 
Samba on the same OES 2 server as Novell AFP, Novell CIFS, or Domain Services for Windows, 
which is not reviewed as a file service, but does include an alternative Samba file service. 


17.1.1 Using the File Services Overviews 


Each graphical overview in the following sections introduces one of the OES file service 
components. If visual presentations help you grasp basic concepts, continue with the following 
overviews. If you prefer to skip the overviews, go to Section 17.2, "Planning for File Services," on 
page 200. 


17.1.2 FTP Services 


OES 2 NetWare has an FTP server that provides for securely transferring files to and from NetWare 
volumes. You can perform file transfers from any FTP client by using the NetWare FTP Server to 
log in to eDirectory™. For more information, see the NW 6.5 SP8: Novell FTP Administration 
Guide. 


OES 2 Linux offers a level of integration between eDirectory and Pure-FTP that allows users to 
authenticate to eDirectory for FTP access to the server. You simply select the Novell FTP Server 
pattern in the OES 2 Linux installation and then make sure the users needing access are LUM- 
enabled and have access rights to the areas on the server they need to use. You can also migrate an 
existing FTP server configuration from a NetWare server to OES 2 Linux. 


For migration instructions and a brief FAQ, see “Migrating FTP from NetWare to OES 2 Linux” in 
the OES 2 SP2: Migration Tool Administration Guide. 


For documentation on Pure-FTP, visit the Pure-FTP Web site (http://pureftpd.sourceforge.net/ 
documentation.shtml). 


17.1.3 Native File Access Protocols 
The Novell Native File Access Protocols (NFAP) product lets users on Macintosh, Windows, and 


UNIX workstations access and store files on OES 2 NetWare servers without installing any 
additional software, such as the Novell Client!" (see Figure 17-1). 
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Figure 17-1 Native File Access Protocol Support on NetWare 
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The following table explains the information illustrated in Figure 17-1. 


Table 17-1 NFAP Access 


Access Methods 


Linux, UNIX, Macintosh, and Windows 
workstation users can create drive 
mappings, mount points, etc., to the 
NetWare server. Then they can access 
the files as though they were stored ona 
network server that is native for the 
respective platforms. 


Authentication/File Encryption 


All file service access is 
controlled by LDAP- based 
authentication through the 
eDirectory LDAP server. 


Although shown separately, 
eDirectory could be installed on 
the OES 2 server. 


After the service is fully 
configured, users can log in just 
as they would to access files on 
other native systems. 


17.1.4 NetWare Core Protocol 


NFAP server 
processes 


OES 2 NetWare 


NFAP y didis 


NFAP Services 


Files are stored on NSS 
volumes on OES 2 
NetWare servers. The 
same files can be 
accessed by users on 
different platforms. 


NetWare Core Protocol (NCP) is the technology beneath many of the network services for which 


NetWare is famous. 
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In OES 2, NCP is also available on Linux. The Novell NCP Server for Linux provides the rich file 
services that Novell is known for. Windows and Linux users who run Novell Client software can 
now access data, manage files and folders, map drives, etc., using the same methods as they do on 


NetWare servers. 


Figure 17-2 illustrates the basics of NCP file services. For more information on how NCP can help 
you manage access to network resources, see “Access Control and Authentication” on page 169. 


Figure 17-2 NCP Services for Linux and NetWare 
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The following table explains the information illustrated in Figure 17-2. 


Table 17-2 NCP Access 


Access Methods Authentication 
Access is through an NCP All file service access is 
client—specifically, the Novell controlled by eDirectory 
Client. authentication. 


17.1.5 NetStorage 


* “Common Network File Storage Problems" on page 191 
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NCP Services 


Files are stored on NetWare or 
NCP volumes that the 
administrator has created. 


The same core set of NetWare file 
attributes are available on both 
Linux and NetWare. 


* “Novell NetStorage on Linux" on page 192 
* "Novell NetStorage on NetWare" on page 193 


NetStorage makes network files available anywhere, any time. 


Common Network File Storage Problems 


Network file access is often confusing and frustrating to users, as illustrated in Figure 17-3. 


Figure 17-3 Common Network File Storage Problems 
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The following table explains the information illustrated in Figure 17-3. 
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Table 17-3 NetStorage Access Solutions 


Access Methods Authentication Target File Systems Solution: NetStorage 
Browser or PDA accessis Authentication helps Having diverse file Novell NetStorage ties 
critical to those who must protect information storage services only all of these issues 
travel. However, access assets, but having diverse adds to the complexity together with an easy- 
method support varies authentication methods and confusion. to-administer, easy-to- 
widely among file service leads to frustration and use solution. 
providers. lost productivity. 


Novell NetStorage on Linux 


NetStorage on Linux provides local and Web access to files on many systems without requiring the 
Novell Client (see Figure 17-4). 


Figure 17-4 How NetStorage Works on OES 2 Linux 
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The following table explains the information illustrated in Figure 17-4. 


192 NW 6.5 SP8: Planning and Implementation Guide 


Table 17-4 NetStorage on Linux 


Access Methods 


Users have read and write 
access to files from 


* Windows Explorer: 
Enabled by the HTTP 
protocol with WebDAV 
extensions. 


* Browsers: Users can 
access files directly by 
connecting to the 
NetStorage server. 


* PDAs: PDA users with 


network connections 


can access their files as 


well. 


Access is granted through 
login script drive mapping 
(NCP server required) or 

through Storage Location 

Objects. 


Authentication 


File service access is 
controlled by LDAP- 
based authentication 


through the eDirectory 


LDAP server. 


Although shown 
separately, eDirectory 
could be running on 
the OES 2 server. 


Novell NetStorage on NetWare 


NetStorage Server 


The NetStorage 
server receives and 
processes 
connection requests 
and provides access 
to storage on various 
servers on the 
network. 


Target Servers 


NetStorage on Linux can 
connect eDirectory users 
to their files and folders 
stored in the following 
locations: 


+ The same targets as 
NetWare (see 
Figure 17-5 on 
page 194) if the 
NCP server is 
running 


* Windows workgroup 
shares (CIFS or 
Samba shares) 


* Linux POSIX 
volumes through an 
SSH connection. 


Linux volumes can also 
be made available as 
NCP volumes. 


Management of NSS 
volumes on OES 2 Linux 
through NetStorage 
requires SSH access to 
the server. See "When Is 
SSH Access Required?" 
on page 97. 


NetStorage on NetWare provides local and Web access to files on NetWare and Linux without 
requiring the Novell Client software (see Figure 17-5). 
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Figure 17-5 How NetStorage Works on OES 2 NetWare 
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The following table explains the information illustrated in Figure 17-5. 
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Table 17-5 NetStorage on NetWare 


Access Methods 


Users have read and write 
access to files from 


* Windows Explorer: 
Enabled by the HTTP 
protocol with WebDAV 
extensions. 


* Browsers: Users can 
access files directly by 
connecting to the 
NetStorage server. 


* PDAs: PDA users with 
network connections 
can access their files as 
well. 


Access is granted through 
login script drive mapping or 
through Storage Location 
Objects. 


17.1.6 Novell AFP 


Authentication 


File service access is 
controlled by LDAP- 
based authentication 
through the eDirectory 
LDAP server. 


Although shown 
separately, eDirectory 
could be running on 
the OES 2 server. 


NetStorage Server 


The NetStorage 
Server receives and 
processes 
connection requests 
and provides access 
to storage on various 
servers on the 
network. 


Target Servers 


NetStorage on NetWare 
can connect eDirectory 
users to their files and 
folders stored in the 
following locations: 


* NetWare Traditional 
volumes where 
users have access 
rights 


* NSS volumes on 
either NetWare or 
OES 2 Linux servers 
where users have 
access rights 


* Any administrator- 
defined NCP 
volumes created on 
an OES 2 Linux 
server 


The Novell AFP service lets users on Macintosh workstations access and store files on OES 2 Linux 
servers with NSS volumes without installing any additional software, such as the Novell Client™ 


(see Figure 17-6). 


Figure 17-6 How Novell AFP Works 
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Table 17-6 AFP Access 


Access Points 


eDirectory users on Macintosh 


Authentication 


All file service access is 


workstations have native access to the 
OES 2 server. 


controlled by LDAP-based 
authentication through the 
eDirectory LDAP server. 


Although shown separately, 
eDirectory could be installed 
on the OES 2 server. 


17.1.7 Novell CIFS 


AFP File Services 


Of course, the same files can 
also be accessed through 
other OES file services (such 
as NetStorage) that connect to 
Linux volumes. 


The Novell CIFS service lets users on Windows workstations access and store files on OES 2 Linux 
servers with NSS volumes without installing any additional software, such as the Novell Client (see 


Figure 17-6). 


Figure 17-7 How Novell CIFS Works 
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Table 17-7  CIFS Access 


Access Methods Authentication CIFS File Services 
eDirectory users on Windows All file service access is Of course, the same files can 
workstations have two native Windows controlled by LDAP-based also be accessed through 
file access options: authentication through the other OES file services (such 
eDirectory LDAP server. as NetStorage) that connect to 
* CIFS Client Access: Windows NSS volumes. 
Explorer users can access and Although shown separately, 
modify files on the OES 2 Linux eDirectory could be installed 
server just as they would on any on the OES 2 server. 


workgroup server share. 


* Web Folder: Users can create Web 
Folders in Windows Explorer or 
Internet Explorer. 


Files on the OES 2 Linux server are 
accessed and maintained with the 
HTTP-WebDAV protocol. 


17.1.8 Novell iFolder 3.7 


Novell iFolder 3.7 supports multiple iFolders per user, user-controlled sharing, and a centralized 
network server for file storage and secure distribution (see Figure 17-8). 
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Figure 17-8 How Novell iFolder Works 
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The following table explains the information illustrated in Figure 17-8. 


Table 17-8 iFolder Access 


Access Methods Authentication/File Encryption Novell iFolder 3.7 Services 
Linux and Windows workstation users All file service access is Slave servers can be 
who have the Novell iFolder Client controlled by LDAP- based added as needed, 
installed can access and modify their authentication through the providing the ability to 
files in one or more workstation folders. eDirectory LDAP server. dynamically grow iFolder 
Changes are automatically synchronized services without disrupting 
with the iFolder 3.7 Enterprise servers. Although shown separately, users. 

eDirectory could be installed on 
A Macintosh client for iFolder 3.7 is the OES 2 server. Local and network copies 
under development and expected to be : of each file are 
released with OES 2 SP1. Files can be encrypted for automatically 

transport using SSL connections | synchronized by the Novell 
A Web interface lets users access their (HTTPS). iFolder Client and Server 


files from any computer with an active 


S pieces. 
network or Internet connection. 
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Additional overview information is available in “Overview of Novell iFolder 3.7 and Later 
Versions” in the Novell iFolder 3.8 Administration Guide. 


17.1.9 Novell Samba 


Samba on an OES 2 Linux server provides Windows (CIFS and HTTP-WebDAV) access to files 
stored on the OES 2 server (see Figure 17-9). 


Figure 17-9 How Samba on OES Works 
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The following table explains the information illustrated in Figure 17-9. 
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Table 17-9 Samba Access 


Access Methods Authentication File Storage Services 
eDirectory users on Windows All file service access is Of course, the same files can 
workstations have two native Windows controlled by LDAP-based also be accessed through 
file access options (if their eDirectory authentication through the other OES file services (such 
accounts have been enabled for LUM eDirectory LDAP server. as NetStorage) that connect to 
and Samba): Linux volumes. 
Although shown separately, 
* CIFS Client Access: Windows eDirectory could be installed 
Explorer users can access and on the OES 2 server. 


modify files on the Samba server 
just as they would on any 
workgroup server share. 


* Web Folder: Users can create Web 
Folders in Windows Explorer or 
Internet Explorer. 


Files on the OES 2 Linux server 
running Samba are accessed and 
maintained with the HTTP-WebDAV 
protocol. 


Samba is an open source initiative. In addition to Linux support, Samba initiatives provide support 
for other platforms such as Apple Computer’s operating systems. More information is available on 
the Web (http://www.samba.org). 


17.2 Planning for File Services 


Functional overviews of each file service product are included in Section 17.1, “Overview of File 
Services,” on page 187. 


* Section 17.2.1, “Deciding Which Components Match Your Needs,” on page 200 
¢ Section 17.2.2, “Comparing Your CIFS File Service Options,” on page 202 


¢ Section 17.2.3, “Planning Your File Services,” on page 203 


17.2.1 Deciding Which Components Match Your Needs 


To decide which file service components to install, you should match service features listed in Table 
17-10 to your network’s file service requirements. 


Table 17-10 OES File Services Feature Breakdown 


Service Access Method Features Back-End Storage Features Security Features 
NCP Server Novell Client (NCP client) * Any Linux volumes * eDirectory 
(NetWare Core (including NSS) that are Authentication 
Protocol) defined as NCP 

volumes 


* NetWare volumes 
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Service 


Access Method Features 


Back-End Storage Features 


Security Features 





NetStorage * Any supported * Linux POSIX volumes * Secure LDAP 
browsers + NetWare volumes Authentication 
* Personal Digital * NCP volumes 
Assistant (PDA) 
* N l 
* Remote (browser- S$ volumes 
based) * Samba (CIFS) servers 
* Web Folders (on * Windows (CIFS) 
either an Internet Servers 
Explorer browser or 
in Windows Explorer) 
* Windows Explorer 
NetWare AFP, * Linux File Managers * NetWare volumes Secure LDAP 
CIFS, and NFS Authentication 


support (Native File 
Access Protocols) 


Macintosh Finder* 
UNIX File Managers 
Windows Explorer 











Novell AFP * Macintosh Chooser * NSS volumes Secure LDAP 
Authentication 
Novell CIFS * Any CIFS client * NSS volumes Secure LDAP 
* Remote access (Web Rumentication 
Folders in the 
Internet Explorer 
browser) 
* Windows Explorer 
Novell iFolder 3.7 * Linux File Managers * Novell iFolder 3.7 Files can be 
] Enterprise server file encrypted for 
* Macintosh Chooser 
i . repository on OES 2 transport through 
* Offline access with Linux server SSL (HTTPS). 
file synchronization 
(between local and Secure L DAF 
Authentication 


network copies) on 
reconnect 


Web browsers 


Windows Explorer 





Novell Samba 
(Linux only) 


Any CIFS client 


Remote access (Web 
Folders in the 
Internet Explorer 
browser) 


Windows Explorer 


Linux POSIX file 
system on OES 2 
server 


NSS volumes 


Secure LDAP 
Authentication 
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17.2.2 Comparing Your CIFS File Service Options 


OES 2 SP1 offers three file services that use the CIFS protocol: Novell CIFS, Novell Samba, and 
Samba in Domain Services for Windows (DSfW). 


Table 17-11 Comparing OES 2 CIFS Solutions 


Item Novell CIFS 


Authentication A Password policy that 
allows the CIFS proxy 
user to retrieve 
passwords is required. 


Novell Samba 


A Samba-compatible 
Password policy is 
required for compatibility 
with Windows workgroup 
authentication. 


Samba in DSfW 


The Domain Services 
Password policy is required 
for DSfW users. The domain 
is set up as a trusted 
environment. 


DSfW uses Active Directory 
authentication methods, such 
as Kerberos’, to ensure that 
only authorized users can log 
in to the domain. 





File system NSS is the only file 
support system supported for this 
release. 


It is recommended (but not required) that you create 
Samba shares on NSS data volumes. 


NSS is fully integrated with eDirectory for easier 
management, and using an NSS volume allows you to 
take advantage of the rich data security model in NSS. 
You can use either iManager or the nssmu utility to create 
an NSS volume on an OES 2 Linux server. For 
instructions on how to set up an NSS volume, see 
“Managing NSS Volumes” in the NW 6.5 SP8: File 
Systems Management Guide. 





LUM and Samba LUM and Samba 
enablement enablement are not 
required. 
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Users must be enabled 
for LUM and Samba and 
assigned to a Samba 


group. 


eDirectory users in the 
domain (eDirectory partition) 
are automatically Samba 
users and are enabled to 
access Samba shares. See 
"Creating Users" in the OES 2 
SP2: Domain Services for 
Windows Administration 
Guide. 


Domain users are set up with 
the necessary UID and default 
group (DomainUsers) 
membership. 


Every additional eDirectory 
group created within the 
domain is automatically Linux- 
enabled. 


Item 


Novell CIFS Novell Samba Samba in DSfW 


Username and The same username and The same username and eDirectory users in the 


password 


password must existon password must existon domain (eDirectory partition) 
both the Windows both the Windows can log into any workstation 
workstation and in workstation and in that has joined the domain. 
eDirectory. eDirectory. There is no need fora 


corresponding user object on 
the workstation. 


17.2.3 Planning Your File Services 


1 For the file services you plan to install, compute the total additional RAM required (above the 
basic system requirement). 


* 


Native File Access Protocols: There are no additional RAM requirements. 
NCP: There are no additional RAM requirements. 

NetStorage: There are no additional RAM requirements. 

Novell AFP: There are no additional RAM requirements. 

Novell CIFS: There are no additional RAM requirements. 








Z 


ovell iFolder 3.7: Suggestions for calculating the additional RAM you need are 
contained in “Server Workload Considerations” in the Novell iFolder 3.8 Administration 
Guide. 


Samba: There are no additional RAM requirements. 


2 Record the additional required RAM in your planning notes. 


3 For the file services you plan to install, compute the total additional disk space required (above 
the basic system requirement). 


* 


Native File Access Protocols: Allocate enough disk space to meet your users' file storage 
needs. Because all platforms can access the same storage space, you need only consider 
the total space needed, not the platform-specific requirements. 


NCP: Allocate enough disk space to meet your users’ file storage needs. On Linux, this 
space must exist on partitions you have designated as NCP volumes. On NetWare, all 
volumes are accessible through NCP. 


NetStorage: There are no disk space requirements because NetStorage provides access 
only to other file storage services. 


Novell AFP: Allocate enough disk space for the partition containing the /home directories 
to meet your users’ file storage needs. 


Novell CIFS: Allocate enough disk space for the partition containing the /home 
directories to meet your users’ file storage needs. 





Novell iFolder 3.7: Suggestions for calculating the additional disk space you need are 
contained in “Server Workload Considerations” in the Novell iFolder 3.8 Administration 
Guide. 


Samba: Allocate enough disk space for the partition containing the /home directories to 
meet your users’ file storage needs. 


4 Record the additional required disk space in your planning notes. 
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For the file services you plan to install, refer to the information in the OES 2 installation guides 
indicated in the following table and note your planning choices on your planning sheet. 


Edi Series Linux Planning References NetWare Planning References 
roduct 
Native File N/A The following sections in the NW 6.5 
Access SP8: AFP, CIFS, and NFS (NFAP) 
Protocols Administration Guide. 
* "Preparing for CIFS and AFP” 
* "Administrator Workstation 
Prerequisites" 
* "Client Computer Prerequisites" 
NCP "Novell NCP Server / Dynamic Storage Installed by default. No additional 
Technology” in the OES 2 SP2: planning required. 
Installation Guide 
NetStorage "Novell NetStorage" in the OES 2 SP2: “NetStorage Install" in the NW65 SP8: 
Installation Guide Installation Guide 
Novell AFP "Novell AFP Services" in the OES 2 N/A 
SP2: Installation Guide 
Novell CIFS "Novell CIFS for Linux” inthe OES2 N/A 
SP2: Installation Guide 
Novell iFolder "Novell iFolder" in the OES 2 SP2: N/A 
3.7 Installation Guide 
Samba “Novell Samba" in the OES 2 SP2: N/A 


Installation Guide 


17.3 Coexistence and Migration of File Services 


Storing shared data on network servers is only half of the picture. The other half is making it 
possible for users of Windows, Macintosh, and UNIX/Linux workstations to access the data. In 
some networks, the installation of special software is permitted on the workstations to provide client 
access. Others require users to be able to access shared data without installing extra software on the 
workstation. 


This section discusses migration of the following services: 


* 


* 


Section 17.3.1, *Novell Client (NCP)," on page 205 

Section 17.3.2, “Native File Access Protocols," on page 205 
Section 17.3.3, *NetStorage," on page 205 

Section 17.3.4, “Novell AFP," on page 205 

Section 17.3.5, *Novell CIFS," on page 206 

Section 17.3.6, “Novell iFolder 3.7," on page 206 

Section 17.3.7, “Samba,” on page 206 
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17.3.1 Novell Client (NCP) 


Novell Client for Windows is the long-standing software solution for providing NCP access to 
NetWare data from Windows workstations. The Novell Client extends the capabilities of Windows 
desktops to access the full range of Novell services, such as authentication to eDirectory, network 
browsing and service resolution, and secure file system access. It supports traditional Novell 
protocols such as NCP, RSA, and NDAP, and it interoperates with open protocols such as LDAP. For 
more information on the Novell Client for Windows, see the Novell Client 4.91 SP5 for Windows 
XP/2003 Installation and Administration Guide. 


The Novell Client for Linux provides these same services for Linux workstations. For more 
information on the Novell Client for Linux, see the Novell Client 2.0 SP2 for Linux Administration 
Guide. 


Because NCP is now available on Linux, Novell Client users can attach to OES 2 Linux servers as 
easily as they have been able to attach to NetWare servers. The NCP Server for Linux enables 
support for login script, mapping drives to OES 2 Linux servers, and other services commonly 
associated with Novell Client access. 


For more information on NCP Server for Linux, see the OES 2 SP2: NCP Server for Linux 
Administration Guide. 


17.3.2 Native File Access Protocols 


On NetWare servers, the Native File Access Protocols (NFAP) service allows users of Windows, 
Macintosh, and UNIX/Linux workstations to access NetWare server data through their native 
interfaces. No Novell Client software is required. 


With NFAP, Windows workstations can access data through the Common Internet File System 
(CIFS) protocol. Macintosh workstations can access data through the Apple Filing Protocol (AFP). 
UNIX/Linux workstations can access data through the Network File System (NFS) protocol. 


17.3.3 NetStorage 


NetStorage provides Web access to the files and directories on OES 2 servers from browsers and 
Web-enabled devices such as PDAs. 


In OES 2, NetStorage is available for both NetWare and Linux and both are capable of pointing to 
the file systems on the other. Because NetStorage is a service that facilitates access to file services in 
various locations but doesn't actually store files, there are no coexistence or migration issues to 
consider. 


For more information about NetStorage, see the NW 6.5 SP8: NetStorage Administration Guide or 
the OES 2 SP2: NetStorage for Linux Administration Guide. 


17.3.4 Novell AFP 


Novell AFP provides native AFP protocol access from Macintosh workstations to data on OES 2 
Linux servers, offering the same basic AFP connectivity that was previously available only on 
NetWare. No Novell Client software is required. 


For information on migrating AFP services from NetWare to OES 2 Linux, see “Migrating AFP 
from NetWare to OES 2 SP2 Linux ” in the OES 2 SP2: Migration Tool Administration Guide. 
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17.3.5 Novell CIFS 


Novell CIFS provides native CIFS protocol access from Windows workstations to data on OES 2 
Linux servers, offering the same basic CIFS connectivity that was previously available only on 
NetWare. No Novell Client softward is required. 


For information on migrating CIFS services from NetWare to OES 2 Linux, see “Migrating CIFS 
from NetWare to OES 2 SP2 Linux” in the OES 2 SP2: Migration Tool Administration Guide. 


17.3.6 Novell iFolder 3.7 


iFolder 3.7 supports multiple iFolders per user, user-controlled sharing, and a centralized network of 
servers to provide scalable file storage and secure distribution. Users can share files in multiple 
iFolder folders, and share each iFolder folder with a different group of users. Users control who can 
participate in an iFolder folder and their access rights to the files in it. Users can also participate in 
iFolder folders that others share with them. 


Novell iFolder 3.7 is available only on OES 2 Linux. 


For information on migrating from iFolder 2 to iFolder 3.7, see “Migrating iFolder 2.x” in the OES 
2 SP2: Migration Tool Administration Guide. 


17.3.7 Samba 


OES 2 Linux includes Samba software to provide Microsoft CIFS and HTTP-WebDAV access to 
files on the server. This is especially useful to those who don’t want to use the Novell Client. 


There is no migration path from Novell CIFS (NFAP) to Samba. 


For more information about Samba in OES 2, see the OES2 SP2: Samba Administration Guide. 


17.4 Aligning NCP and POSIX File Access Rights 


NetWare administrators have certain expectations regarding directory and file security. For example, 
they expect that home directories are private and that only the directory owners can see directory 
contents. However, because of the differences in the NetWare Core Protocol (NCP) and POSIX file 
security models (see Section 21.2.1, “Comparing the Linux and the NetWare Core Protocol (NCP) 
File Security Models,” on page 229) that is not the case by default on POSIX file systems. 


Fortunately, when you install Linux User Management (LUM) in OES 2, there is an option to make 
home directories private. This option automatically provides the privacy that NetWare 
administrators are used to seeing. Unfortunately, the option only applies to newly created home 
directories, so there is more to understand and do if aligning access rights is an issue for you. 


Use the information in this section to understand how you can configure POSIX directories to more 
closely align with the NCP model. 

* Section 17.4.1, “Managing Access Rights,” on page 207 

* Section 17.4.2, “Providing a Private Work Directory," on page 208 

* Section 17.4.3, “Providing a Group Work Area,” on page 208 

* Section 17.4.4, “Providing a Public Work Area,” on page 209 

* Section 17.4.5, “Setting Up Rights Inheritance,” on page 209 
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17.4.1 Managing Access Rights 


NCP directories are, by default, private. When you assign a user or a group as a trustee of a directory 
or file, those trustees can automatically navigate to the assigned area and exercise whatever access 
privileges you have assigned at that level and below. You can assign as many trustees with different 
access privileges as you need. 


On the other hand, Linux POSIX directories can be accessed through three sets of permissions 
defined for each file object on a Linux system. These sets include the read (r), write (w), and execute 
(x) permissions for each of three types of users: the file owner, the group, and other users. The Linux 
kernel in OES 2 also supports access control lists (ACLs) to expand this capability. However, ACLs 
are outside the scope of this discussion. For more information on ACLs, see “Access Control Lists” 
(http://www.novell.com/documentation/sles10/book_sle_reference/data/cha_acls.html) in the SLES 
10 SP2: Installation and Administration Guide (http://www.novell.com/documentation/sles10/ 
book sle reference/data/book sle reference.html). 


The Linux chown command lets you change the file owner and/or group to a LUM user or a LUM- 
enabled group. For example, chown -R userl /home/user1 changes the owner of the user1 
home directory and all its subdirectories and files to user1. For more information, see the chown 
man page on your OES 2 Linux server. 


The Linux chmod command provides a very simple and fast way of adjusting directory and file 
access privileges for the three user types: owner, group, and other (all users). In its simplest form, 
the command uses three numbers, ranging from 0 through 7, to represent the rights for each of the 
three user types. The first number sets the rights for the owner, the second number sets the rights for 
the group, and the third number sets the rights for all others. Each number represents a single 
grouping of rights, as follows: 


Number Setting Binary Representation 
0 see 000 
1 --X 001 
2 -W- 010 
3 -WX 011 
4 r-- 100 
5 r-x 101 
6 rw- 110 
7 rwx 111 


Those familiar with the binary number system find this method an easy way to remember what each 
number represents. 


For example, the command chmod 777 /home would grant read, write and execute rights (7) to 
owner, group, and other for the /home directory, while chmod 700 /home would grant the three 
rights to only the directory owner, with group and other having no rights. chmod 750 /home would 
grant rwx rights to the owner, r-x rights to the group, and no rights to other users. 


For more information about the chmod command, see the chmod man page on your OES 2 Linux 
server. 
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17.4.2 Providing a Private Work Directory 


To make an NCP directory private, you assign a single user as the trustee and make sure that no 
unexpected users or groups have trustee rights in any of the parent directories. 


To provide a private work area on a Linux POSIX volume: 


1 Make the user is the directory owner. For example, you could use the chown command to 
change the owner (user), 
chown -R user: /path/user dir 


where user is the eDirectory user, path is the file path to the work directory, and user_dir is the 
work directory name. The -R option applies the command recursively to all subdirectories and 
files. 


2 Grant only the user read, write, and execute rights (rwx --- --- ) to the directory. For example, 
you could use the chmod command as follows, 


chmod -R 700 /path/user dir 
where path is the file path to the work directory, and user_dir is the work directory name. 


3 Check each parent directory in the path up to the root (/) directory, making sure that all users 
(referred to as “other users" in Linux) have read and execute rights (r-x) in each directory as 
shown by the third group of permissions (...... I-X). (Owner and group permissions are 
represented by dots because their settings are irrelevant.) 


The reason for checking directories is that in the parent directories the directory owners are 
“other” users and they need to be able to see the path down to their own private directories. 


Because r-x is the default for most directories on Linux, you probably won't need to change the 
permissions. 


17.4.3 Providing a Group Work Area 


On an NCP volume, you can provide a group work area by assigning users to a group and then 
granting the group trustee rights to the directory. As an alternative, if users need different levels of 
access within the work area, you can assign each user as a trustee and grant only the rights needed. 


To provide a group work area on a Linux POSIX volume: 
1 Use the chown command to set group ownership for the directory. For example, you could enter 


chown -R :group /path/group dir 


where group is the group name, path is the file path to the work area, and group dir is the 
group work directory. The -R option applies the action to all subdirectories and files in 
group dir. 


2 Grant the group read, write, and execute rights (. . . rwx . . .). (Owner and other permissions are 
represented by dots because their settings are irrelevant.) 


For example, you could enter 
chmod -R 770 /path/group dir 


where path is the file path to the work area, and group. dir is the group work directory. The 
second 7 grants rwx to the group. (The example assumes that the owner of the directory should 
also retain all rights. Therefore, the first number is also 7.) 
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3 Check each parent directory in the path up to the root (/) directory, making sure that the 
group has read and execute rights (r-x) in each directory as shown by the second group of 
permissions (...1-x...). 

Use the chmod command to adjust this where necessary by specifying the number 5 for the 
group permission. For more information, see “Section 17.4.1, “Managing Access Rights,” on 
page 207.” 


17.4.4 Providing a Public Work Area 


On an NCP volume, you can provide a public work area by assigning [Public] as a trustee and then 
granting the required trustee rights to the directory. 


For the work area itself, you would set permissions for the owner, group, and all others to read, 
write, and execute rights (rwx rwx rwx) (chmod 777). 


All others must also have read and execute rights on the system in each parent directory in the path 
all the way to the root of the Linux system. This means that you set permissions for all parent 
directories to rwx --- r-x. 


To provide a public work area on a Linux POSIX volume: 


1 Use the chown command to assign all rights (rwx) to other (all users). For example, you could 
enter 


chmod -R 707 /path/group dir 


where path is the file path to the work area, and group dir is the group work directory. The 
third 7 grants rwx to the group. (The example assumes that the owner of the directory should 
also retain all rights and that the group setting is irrelevant.) 


2 Check each parent directory in the path up to the root (/) directory, making sure that all users 
(other) have read and execute rights (r-x) in each directory as shown by the third group of 
permissions (...... rwx). (Owner and group permissions are represented by dots because their 
settings are irrelevant.) 

Use the chmod command to adjust this where necessary by specifying the number 5 for the 
other permission. For more information, see “Managing Access Rights" at the beginning of this 
section. 


17.4.5 Setting Up Rights Inheritance 


The final step in aligning POSIX rights to the NCP model is setting the Inherit POSIX Permissions 
volume flag in the NCP configuration file so that all files and subdirectories created in these areas 
inherit the same permissions as their parent directory. For instructions, see *Configuring Inherit 
POSIX Permissions for an NCP Volume" in the OES 2 SP2: NCP Server for Linux Administration 
Guide. 


17.5 Native File Access Protocols 
Implementation and Maintenance 


After installing a NetWare server, if you want to provide native access to Linux, Macintosh, UNIX, 
or Windows users, there are tasks to complete for each of the platforms. 
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The NW 6.5 SP8: AFP, CIFS, and NFS (NFAP) Administration Guide contains the following 
relevant sections: 


* “Working with UNIX Machines” 
* “Working with Macintosh Computers” 


* “Working with Windows Computers” 


To ensure a successful NFAP implementation, complete all the instructions in the sections for your 
chosen platforms. 


Because NFAP provides native protocol access to files on NSS volumes on the NetWare server, the 
service is covered by maintenance tasks that apply to NSS file systems. For information on 
maintaining file services on NetWare, see the “Storage and File Systems” links in the online 
documentation. 


17.6 NCP Implementation and Maintenance 


The implementation information in the following sections can help you get started with NCP on 
OES 2 servers. 


* Section 17.6.1, “NCP Services on NetWare,” on page 210 

* Section 17.6.2, “Novell NCP Server for Linux,” on page 210 
* Section 17.6.3, “Assigning File Trustee Rights,” on page 211 
* Section 17.6.4, “NCP Maintenance,” on page 211 


17.6.1 NCP Services on NetWare 


After installing an OES 2 NetWare server, eDirectory users on Windows workstations with the 
Novell Client installed can access all the directories and files that you have granted them access to. 


A common way for granting access is using the menu button (the red N) located in the system tray 
(taskbar) on most workstations after the Novell Client is installed. More information about 
managing file access is available in Chapter 16, “Access Control and Authentication,” on page 169. 


17.6.2 Novell NCP Server for Linux 


If you have installed the NCP Server for Linux, the same eDirectory/Novell Client users can access 
files on the OES 2 Linux server. 


* “The Default NCP Volume" on page 210 


* “Creating Home and Data Volume Pointers” on page 211 


The Default NCP Volume 


The NCP Server for Linux enables NCP access to NCP volumes defined on the OES 2 Linux server. 
When you install the NCP server, the installation creates one NCP volume named sys : that maps to 
the /usr/novell/sys folder on the Linux server. 


This NCP volume contains LOGIN and PUBLIC directories that, in turn, contain a small subset of the 
files found on a NetWare server in the directories with the same names. 
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Creating Home and Data Volume Pointers 


Initially, there are no NCP home directories or data volumes available to Novell Clients that attach 
to an OES 2 Linux server. 


For existing eDirectory users: If you want users to have NCP home or data directories on the 
server, you must decide where you want these directories to reside on the server’s partitions and then 
create NCP volumes by using the NCPCON utility at the Linux command prompt. 





For example, if you wanted to create an NCP volume (pointer) named HOME and mount it to the /usr 
folder on the Linux server, you would enter the following command at the command prompt: 





ncpcon create volume HOME /usr 





After issuing this command, when a Novell Client attaches to the OES 2 Linux server, the HOME: 
volume appears along with the SYS: volume created by the installation. 


For new eDirectory users: If you create an NCP or NSS volume on the server prior to creating 
users, then you have the option of specifying that volume in iManager as the location of the home 
directory for the new users. 





IMPORTANT: NCP Volume pointers are always created with uppercase names (HOME : , SYS:, etc.) 
regardless of the case specified when the volume pointers are created. 





17.6.3 Assigning File Trustee Rights 


You can use the same methods for assigning file trustee rights on NCP volumes on OES 2 Linux 
servers that you use when assigning them on NetWare. For example, the Novell Client can be used 
by anyone with the Access Control right on the volume, or the root user can use the ncpcon utility > 
rights command at a command prompt to administer NCP trustee rights. See *Managing File 
System Trustees, Trustee Rights, and Attributes on NCP Volumes"in the OES 2 SP2: NCP Server 
for Linux Administration Guide. (The ncpcon rights command is related to but not the same as the 
rights utility used to manage trustees on NSS volumes.) 


17.6.4 NCP Maintenance 


Because NCP provides Novell Client access to files on OES 2 NetWare and OES 2 Linux servers, 
the service is covered by maintenance tasks that apply to file systems on these servers. For 
information on maintaining file services, see the “NetWare 6.5 SP8” section in the online 
documentation. 


17.7 NetStorage Implementation and 
Maintenance 


The following sections are provided only as introductory information. For more information about 
using NetStorage, see the NW 6.5 SP8: NetStorage Administration Guide. 

* Section 17.7.1, *About Automatic Access and Storage Locations," on page 212 

* Section 17.7.2, *About SSH Storage Locations," on page 212 

* Section 17.7.3, “Novell iFolder 2 Doesn't Use Storage Locations," on page 212 

* Section 17.7.4, *Assigning User and Group Access Rights," on page 213 
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* Section 17.7.5, “Authenticating to Access Other Target Systems," on page 213 
* Section 17.7.6, *NetStorage Authentication Is Not Persistent by Default," on page 213 
* Section 17.7.7, *NetStorage Maintenance," on page 214 


17.7.1 About Automatic Access and Storage Locations 
The inherent value of NetStorage lies in its ability to connect users with various servers and file 


systems. Some connections are created automatically depending on the OES platform where 
NetStorage is installed. Other connections must be created by the network administrator. 


Table 17-12 NetStorage Access Summary 


OES Platform Automatic Access 
Linux * NSS volumes on the same server that use the default mount point (/media/ 
nss) 


* User Home directories that are specified in eDirectory on NCP or NSS 
volumes. 


* Drive mapping locations in login scripts of the user logging in (if the NCP 
Server for Linux is running on the server) 





NetWare * User Home directories 
* Novell iFolder 2 folders on the same server 


* Drive mapping locations in login scripts of the user logging in 


To provide access to file systems not listed in Table 17-12, you must create Storage Location objects 
in eDirectory. For instructions on creating Storage Locations, see the following: 


* For Linux: "Creating a Storage Location Object" in the OES 2 SP2: NetStorage for Linux 
Administration Guide 


* For NetWare: "Creating a Storage Location Object" in the NW 6.5 SP8: NetStorage 
Administration Guide 


17.7.2 About SSH Storage Locations 


If you plan to use SSH storage locations, be aware that by default any users who are enabled for 
Samba cannot access data stored at the SSH locations. Additional steps are required to grant 
simultaneous access to Samba and SSH. For more information, see Section 11.4, *SSH Services on 
OES 2 Linux," on page 96. 


17.7.3 Novell iFolder 2 Doesn't Use Storage Locations 
Novell iFolder 2 access in NetStorage is controlled through the iFolder Storage Provider task in 


iManager and does not involve Storage Location objects. For more information about the iManager 
task, see the context-sensitive help in iManager. 
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17.7.4 Assigning User and Group Access Rights 


Because NetStorage provides access to other file storage systems, the users and groups that access 
the other systems through NetStorage must be created and granted file and directory access on those 
systems. 


For example: 
* NetWare users must exist in the eDirectory tree where the NetWare server resides and have 
access rights to the files and directories on the NetWare server. 


* Windows users must exist on the Windows systems and have the required access rights to the 
files and directories on those systems. 


+ |f your users will access Samba files on an OES 2 Linux server, they must be enabled for LUM 
and Samba access on the OES 2 Linux server. For more information, see Services in OES 2 
Linux That Require LUM-Enabled Access" on page 156. 





IMPORTANT: The usernames and passwords used to authenticate to the NetStorage (OES) server 
through eDirectory must match the usernames and passwords defined on the target systems. 





17.7.5 Authenticating to Access Other Target Systems 


The OES installation establishes a primary authentication domain for NetStorage. To access any 
storage location, users must exist somewhere in this primary domain. When it receives an 
authentication request, NetStorage searches for the username in the context you specified during 
OES installation and in all its subcontexts. 


Authentication to other file systems is often controlled by other authentication domains. For 
example, you might create a storage location on the OES 2 server that points to a NetWare server 
that resides in a different eDirectory tree. To access this storage location, users must authenticate to 
the other tree. 


This means that you must specify an additional context in the NetStorage configuration as a 
nonprimary authentication domain. 


When defining a nonprimary authentication domain, you must 


* Ensure that the username and password in the nonprimary domain matches the username and 
password in the primary domain. 


* Specify the exact context where User objects reside. NetStorage doesn't search the subcontexts 
of nonprimary authentication domains. 


For more information about managing NetStorage authentication domains, see "Authentication 
Domains" in the NW 6.5 SP8: NetStorage Administration Guide and see “Authentication Domains” 
in the OES 2 SP2: NetStorage for Linux Administration Guide. 


17.7.6 NetStorage Authentication Is Not Persistent by Default 


By default, users must reauthenticate each time they access NetStorage in a browser. This is true 
even if another browser window is open and authenticated on the same workstation. 


The reason for this is that persistent cookies are not enabled by default. 


File Services 


213 


This setting can be changed. For more information, see “Persistent Cookies” in the NW 6.5 SP8: 
NetStorage Administration Guide and “Persistent Cookies” in the OES 2 SP2: NetStorage for Linux 
Administration Guide. 


17.7.7 NetStorage Maintenance 


Your NetStorage installation can change as your network changes and evolves by providing access 
to new or consolidated storage locations. For information about the kinds of tasks you can perform 
to keep your NetStorage implementation current, see the following: 


¢ For Linux: OES 2 SP2: NetStorage for Linux Administration Guide 
* For NetWare: NW 6.5 SP8: NetStorage Administration Guide 


17.8 Novell AFP Implementation and 
Maintenance 


To use the Novell implementation of AFP file services on your OES 2 Linux server, you must install 
the service by using the instructions in the OES 2 SP2: Installation Guide (for a new installation) or 
install it after the initial OES installation, as explained in “Installing AFP after the OES 2 SP 2 
Installation” in the OES 2 SP2: Novell AFP For Linux Administration Guide. 

* Section 17.8.1, "Implementing Novell AFP File Services,” on page 214 


* Section 17.8.2, “Maintaining Novell AFP File Services,” on page 214 


17.8.1 Implementing Novell AFP File Services 





NOTE: If you are new to OES, we recommend the OES 2 SP2: Lab Guide for Linux and Virtualized 
NetWare for an introduction to creating and working with eDirectory objects and OES 2 file 
services, including Novell AFP. 





All eDirectory users can access the AFP file services on an OES 2 Linux server as they would any 
Macintosh server. 


17.8.2 Maintaining Novell AFP File Services 


Information on maintaining your AFP installation is found in the OES 2 SP2: Novell AFP For Linux 
Administration Guide. 


17.9 Novell CIFS Implementation and 
Maintenance 


To use the Novell implementation of CIFS file services on your OES 2 Linux server, you must 
install the service by using the instructions in the OES 2 SP2: Installation Guide (for a new 
installation) or install it after the initial OES installation, as explained in “Installing and Configuring 
a CIFS Server through YaST” in the OES 2 SP2: Novell CIFS for Linux Administration Guide. 

* Section 17.9.1, “Implementing Novell CIFS File Services,” on page 215 


* Section 17.9.2, *Maintaining Novell CIFS File Services," on page 215 
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17.9.1 Implementing Novell CIFS File Services 





NOTE: If you are new to OES, we recommend the OES 2 SP2: Lab Guide for Linux and Virtualized 
NetWare for an introduction to creating and working with eDirectory objects and OES 2 file 
services, including Novell CIFS. 





All eDirectory users can access the CIFS file services on an OES 2 Linux server as they would any 
Windows workgroup server. 


For instructions on implementing Novell CIFS, see “Planning and Implementing CIFS” in the OES 
2 SP2: Novell CIFS for Linux Administration Guide. 


17.9.2 Maintaining Novell CIFS File Services 


Information on maintaining your CIFS installation is found in the OES 2 SP2: Novell CIFS for Linux 
Administration Guide. 


17.10 Novell iFolder 3.7 Implementation and 
Maintenance 


The following implementation pointers are provided only as introductory information. To begin 
using Novell iFolder, see the Novell iFolder 3.8 Administration Guide. 


* Section 17.10.1, “Managing Novell iFolder 3.7," on page 215 

* Section 17.10.2, "Configuring Novell iFolder 3.7 Servers," on page 215 

¢ Section 17.10.3, “Creating and Enabling Novell iFolder 3.7 Users,” on page 215 
* Section 17.10.4, *Novell iFolder 3.7 Maintenance," on page 216 


17.10.1 Managing Novell iFolder 3.7 


You manage Novell iFolder through the iFolder Management Console, which you can access 
directly or through iManager. For more information, see "Accessing the Novell iFolder Web Admin 
? in the Novell iFolder 3.8 Administration Guide. 


17.10.2 Configuring Novell iFolder 3.7 Servers 


Before you let users log in to the Novell iFolder 3.7 server, be sure you complete all the setup tasks 
in “Installing and Configuring iFolder Services" (including “Configuring the iFolder Web Admin 
Server" if applicable) in the Novell iFolder 3.8 Administration Guide. 


17.10.3 Creating and Enabling Novell iFolder 3.7 Users 


To provide user access to Novell iFolder 3.7: 


]. Provision eDirectory User objects for iFolder 3.7. 
2. Enable the User Account Policies for iFolder access. 


3. (Optional) Enable Account Quotas (space limits) for the user accounts. 
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4. Create iFolders for users. 


5. Distribute the iFolder Client to users. 


For more information, see “Managing iFolder Users” in the Novell iFolder 3.8 Administration 
Guide. 


17.10.4 Novell iFolder 3.7 Maintenance 


As the Novell iFolder service load increases, you might need to increase the server capacity or add 
additional servers. For help, see “Deploying iFolder Server ” in the Novell iFolder 3.8 
Administration Guide. For a list of other common iFolder maintenance topics, see iFolder 3.7 or 
later in the OES 2 online documentation. 


17.11 Samba Implementation and Maintenance 


To use the Novell implementation of Samba file services on your OES 2 server, you must install the 
service by using the instructions in the OES 2 SP2: Installation Guide (for a new installation) or 
install it after the initial OES installation, as explained in "Installing Samba for OES 2" in the OES2 
SP2: Samba Administration Guide. 


* Section 17.11.1, "Implementing Samba File Services," on page 216 
* Section 17.11.2, "Maintaining Samba File Services," on page 216 
17.11.1 Implementing Samba File Services 


All users whose accounts have been enabled for Samba access can access the OES 2 server as they 
would any Windows server. 


For instructions on implementing Samba, see "Installing Samba for OES 2" in the OES2 SP2: 
Samba Administration Guide. 


17.11.2 Maintaining Samba File Services 


Information on maintaining your Samba installation is found in the OES2 SP2: Samba 
Administration Guide. 
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Print Services 


Open Enterprise Server 2 includes Novell® iPrint, a powerful and easy-to-implement printing 
solution that provides print-anywhere functionality to network users. iPrint lets Windows, Linux, 
and Macintosh users quickly locate network printers through a Web browser, easily install and 
configure a located printer through a native printer installation method, and print to installed printers 
from any location through an IP connection. 


This section contains the following information: 


* Section 18.1, “Overview of Print Services," on page 217 

* Section 18.2, “Planning for Print Services," on page 220 

* Section 18.3, “Coexistence and Migration of Print Services,” on page 220 
* Section 18.4, “Print Services Implementation Suggestions," on page 220 


¢ Section 18.5, “Print Services Maintenance Suggestions,” on page 222 


18.1 Overview of Print Services 


Novell iPrint lets Linux, Macintosh, and Windows users 


* Quickly locate network printers through a Web browser. 

* Easily install and configure a located printer through a native printer installation method. 

* Print to installed printers from any location (including the Web) through an IP connection. 
The information in this section provides a high-level overview of Novell iPrint print services. It is 
designed to acquaint you with basic iPrint functionality so you understand the configuration steps 
you need to perform to provide iPrint print services, and understand how iPrint functions from the 
user's perspective. 

* Section 18.1.1, *Using This Overview," on page 217 

* Section 18.1.2, “iPrint Components," on page 218 


* Section 18.1.3, “iPrint Functionality,” on page 218 


18.1.1 Using This Overview 


If you already know that you want to provide OES print services for your users and you understand 
how iPrint works, skip the overviews and continue with Section 18.2, “Planning for Print Services,” 
on page 220. 


If you want to learn more about iPrint, continue with this overview section. 
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18.1.2 iPrint Components 


A Novell iPrint installation consists of various components, most of which are represented by 
objects in your eDirectory™ tree: 


¢ Print Driver Store (Linux): This is a repository that stores the drivers on an OES 2 Linux 
server for your network printers. It is the first component you configure and is represented by 
an eDirectory object that you create. 


¢ Print Broker (NetWare): This is a repository that stores the drivers on an OES 2 NetWare® 
server for your network printers. It is the first component you configure and is represented by 
an eDirectory object that you create. 


¢ Printer Drivers: These are the platform-specific printer drivers and PostScript* Printer 
Description (PPD) files that are stored in the Driver Store or Broker and are installed on 
workstations when users select a target printer. Printer drivers and PPD files exist as file 
structures within the Driver Store and Broker and are not represented by objects in eDirectory. 


* Printer Objects: These are eDirectory objects you create that store information about the 
printers available through iPrint. The information stored in an object is used each time its 
associated printer is added to a workstation's list of available printers. 


* Print Manager: This is a daemon that runs on OES 2 Linux or an NLM™ that runs on the OES 
2 NetWare server. It receives print jobs from users and forwards them to the target printer when 
it is ready. It is represented by and controlled through an eDirectory object that you can 
configure. 


* iPrint Client: This is a set of browser plug-ins. On Macintosh and Windows workstations it is 
automatically installed the first time it interacts with iPrint. On Linux workstations, it must be 
installed manually. The client is required on each platform to navigate through the iPrint Web 
pages, select a target printer, and install the print driver. 


For more information on iPrint, see “Print Services" in the OES online documentation. 


18.1.3 iPrint Functionality 


Figure 18-1 describes how iPrint functions from a user workstation perspective. 
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Figure 18-1 How iPrint Works 
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The following table explains the information illustrated in Figure 18-1. 


Table 18-1 iPrint Functionality 


Access Authentication 


The iPrint Client must be installed You can require authentication for 

on each workstation accessing Windows users if needed. The 

iPrint services. option to require authentication is 
not available for Linux and 


A user needing to use a printer Macintosh users. 


for the first time accesses the 
organization's print page on the Although shown separately, 
Web. eDirectory could be installed on 


the OES 2 server. 
When the user selects the target 


printer, its platform-specific driver 
is automatically installed and 
configured. 


After printer installation, users 
can print to the printer from any 
application. 


Printing Services 


Users with the iPrint Client 
installed and access to the OES 2 
server can install printer drivers 
and print to iPrint printers. 


By default, iPrint generates a 
printer list for the printers hosted 
on the server. 


A customized Web page lets 
users browse to the target printer 
by using location lists and maps 
that you have previously created 
for the site where the printer is 
located. 
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18.2 Planning for Print Services 


Consider the following information as you plan your iPrint installation: 
+ We recommend that you record your planning decisions on a planning worksheet for future 
reference. 
¢ iPrint has no additional RAM requirements. 


¢ Most iPrint installations (even in large enterprises) do not require additional disk space for 
associated print job spooling. 


However, if you anticipate very heavy print usage and want to plan for additional disk space in 
that regard, the iPrint spooler area is located in the /var partition or directory structure on OES 
2 Linux servers. On NetWare servers, you designate the location when creating the Print 
Manager object. 


¢ To finish planning your iPrint installation, refer to the information for your server platform: 
* For NetWare: “Novell iPrint Server" in the NW65 SP8: Installation Guide 
¢ For Linux: “Novell iPrint” in the OES 2 SP2: Installation Guide 


18.3 Coexistence and Migration of Print Services 


If you select iPrint during the OES Linux server installation, the iPrint software components are 
automatically installed on the server. Although the Common UNIX Printing System (CUPS) 
software is also installed with SLES 10, CUPS is disabled to avoid port 631 conflicts. 


For information on upgrading from NetWare queue-based printing, Novell Distributed Print 
Services™ (NDPS), or previous versions of iPrint, see “Installing iPrint Software” in the NW 6.5 
SP6: iPrint Administration Guide. 


For more information on configuring iPrint on OES Linux, see "Installing and Setting Up iPrint on 
Your Server" in the OES 2 SP2: iPrint for Linux Administration Guide. 


In OES SP2, migrating iPrint services from a NetWare server to an OES 2 Linux server is supported 
in Server Consolidation Utility 4.2, which is included in the Novell Server Consolidation and 
Migration Toolkit. For more information, see “Migrating iPrint Printers and Print Managers from 
NetWare to Linux" in the Novell Server Consolidation and Migration Toolkit Administration Guide. 


18.4 Print Services Implementation Suggestions 


This section provides only summary implementation information. For complete iPrint 
documentation, see the OES 2 SP2: iPrint for Linux Administration Guide and the NW 6.5 SP8: 
iPrint Administration Guide. 

* Section 18.4.1, "Initial Setup," on page 221 

* Section 18.4.2, "Implementation Caveats," on page 222 


* Section 18.4.3, *Other Implementation Tasks," on page 222 
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18.4.1 Initial Setup 


After your OES 2 server is installed, you must do the following to complete your iPrint installation: 


1 Create a Driver Store on OES 2 Linux or a Broker on OES 2 NetWare to store the print drivers. 


These eDirectory objects store the drivers for your network printers on Linux and NetWare 
servers, respectively. Each Printer object you create for your network needs to reference a 
printer driver in Driver Store/Broker. When users subsequently install printers, the correct 
drivers for the platform running on their workstation are downloaded from the Driver Store and 
installed. 


You create the Driver Store through iManager. For specific instructions, see the following: 


* For Linux: “Creating a Driver Store” in the OES 2 SP2: iPrint for Linux Administration 
Guide 


* For NetWare: “Creating a Broker" in the NW 6.5 SP8: iPrint Administration Guide 


2 Adda printer driver to the Driver Store or Broker for each printer/platform combination 
needed. 


For example, If you have Windows XP, Windows 2000, and Novell Linux Desktop (NLD) 
workstations on your network and you have four different printer types, you need to add four 
printer drivers for each platform (a total of 12 printer drivers) to the Driver Store or Broker. 


You add printer drivers to the store through iManager. For specific instructions, see the 
following: 


* For Linux: “Updating Printer Drivers” in the OES 2 SP2: iPrint for Linux Administration 
Guide 


* For NetWare: “Adding or Updating Printer Drivers” in the NW 6.5 SP8: iPrint 
Administration Guide 


3 Create a Print Manager object. 


The Print Manager receives print jobs from users and forwards them to the target printer when 
it is ready. The Print Manager must be running for you to create Printer objects. 


The Print Manager is an object you create in eDirectory and is usually started and stopped 
through iManager. 


You create the Print Manager object through iManager. For specific instructions, see the 
following: 


* For Linux: “Creating a Print Manager” in the OES 2 SP2: iPrint for Linux Administration 
Guide 


* For NetWare: “Creating a Print Manager” in the NW 6.5 SP8: iPrint Administration Guide 
4 Create Printer objects. 


You must create a Printer object for each printer you want users to access through iPrint. These 
objects store information about the printer that is used each time the printer is installed on a 
workstation. 


You create Printer objects through iManager. For specific instructions, see the following: 
* For Linux: “Creating a Printer" in the OES 2 SP2: iPrint for Linux Administration Guide 
* For NetWare: “Creating a Printer" in the NW 6.5 SP8: iPrint Administration Guide 
5 (Optional) Create location-based, customized printing Web pages. 
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By default, each iPrint installation includes the creation of a Default Printer List Web page that 
users can access to install iPrint printers. 


You have the option of enhancing the browsing experience by creating location-based printing 
Web pages that feature either lists of printers by location, maps of the buildings showing each 
printer, or a combination of both. 


If your organization is located at multiple sites or even in a building with multiple floors, 
providing location-based print Web pages can greatly simplify printing for your users. 


Your iPrint installation contains the iPrint Map Designer to help you easily create location 
maps with clickable printer icons. For more information, see the following: 


* For Linux: “Setting Up Location-Based Printing” in the OES 2 SP2: iPrint for Linux 
Administration Guide 


* For NetWare: “Setting Up Location-Based Printing" in the NW 6.5 SP8: iPrint 
Administration Guide 


6 Provide instructions to users for accessing iPrint printers. 


After performing the steps above, your network is ready for iPrint functionality. You need only 
tell users how to access your printing Web pages; Novell iPrint does the rest. 


18.4.2 Implementation Caveats 


There are a few implementation caveats relating to iPrint on Linux. See “iPrint” on page 64. 


18.4.3 Other Implementation Tasks 


In addition to the tasks described in Section 18.4.1, “Initial Setup,” on page 221, there are additional 
tasks you might want or need to consider. To see a list of potential tasks, refer to the “Print Services” 
links in the OES online documentation. 


18.5 Print Services Maintenance Suggestions 


As you add printers to your network or move them to different locations, be sure to update your 
iPrint installation to reflect these changes. 


After your installation is completed and users are printing, you can monitor print performance by 
using the information located in the following locations: 


* For Linux: “Using the Print Manager Health Monitor” in the OES 2 SP2: iPrint for Linux 
Administration Guide 


* For NetWare: "Using the Print Manager Health Monitor" in the NW 6.5 SP8: iPrint 
Administration Guide 


For more information on iPrint and its functionality within OES, see the “Print Services" links in the 
online documentation. 
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Search Engine (QuickFinder) 


Open Enterprise Server 2 includes the Novell® QuickFinder™ Server on both the NetWare® and 
Linux platforms. QuickFinder lets you add search and print functionality to any Web site or internal 
intranet. It can index and find matches within a wide variety of data types. It also supports rights- 
based searches so that users see only what they have rights to see, depending on the type of index 
created and the file system indexed. 


QuickFinder replaces the NetWare Web Search Server that was available in NetWare 6.5 SP3 and 
earlier. When you upgrade a NetWare server running NetWare Web Search Server to OES NetWare 
(NetWare 6.5), Web Search Server is automatically upgraded to QuickFinder. The upgrade identifies 
all the configuration settings and indexes from Web Search and enables them to be used by 
QuickFinder. 


When indexing a file system, the QuickFinder engine indexes only what it has rights to see. On 
NetWare, it has full access to all mounted volumes. On Linux, it has rights to only the files that the 
wwwrun user and the www group have rights to see. 


For more information, see the topics in “Search Engine” in the OES 2 online documentation or refer 
to the NW 6.5 SP8 Novell QuickFinder Server 5.0 Administration Guide. 


Search Engine (QuickFinder) 
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Web Services 


The Web and application services in Open Enterprise Server 2 support the creation and deployment 
of Web sites and Web applications that leverage the widespread availability of Internet-based 
protocols and tools. 


With the proper Web components in place, a server can host dynamic Web sites where the content 
changes according to selections made by the user. You can also run any of the hundreds of free Web 
applications that can be downloaded from the Internet. Web and application services make it easy to 
build your own dynamic Web content and create customized Web database applications. 


See the topics in “Web Services” in the OES online documentation. 


OES 2 also includes a Jakarta-Tomcat servlet container for both NetWare® and Linux, including 
Tomcat 4 for NetWare, a Tomcat 5 servlet container on NetWare (for compatibility with iManager 
2.7), and Tomcat 5 for Linux. Tomcat is used to run basic Java servlet and JavaServer Pages* (JSP*) 
applications on either operating system platform. 


Apache 


Apache Web Server 2.0 is the most popular Web server on the Internet. For the most part, Apache 
functions the same on NetWare and Linux, although Apache for NetWare does include some 
additional functions to allow for directory-enabled administration. 


For additional information, see the NW 6.5 SP8: Apache Web Server Administration Guide and the 
Apache.org Web site (http://www.apache.org). 
Tomcat 


OES 2 also includes a Jakarta-Tomcat servlet container for both NetWare and Linux, including 
Tomcat 4 for NetWare, a Tomcat 5 servlet container on NetWare (for compatibility with iManager 
2.7), and Tomcat 5 for Linux. Tomcat is used to run basic Java servlet and JavaServer Pages (JSP) 
applications on either operating system platform. 


For additional information, see the NW 6.5 SP8: Tomcat Administration Guide and the Apache 
Jakarta Tomcat 5.5 Web site (http://tomcat.apache.org/tomcat-5.5-doc/index.html). 
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Security 


This section contains the following topics: 


* Section 21.1, “Overview of OES Security Services,” on page 227 

* Section 21.2, “Planning for Security," on page 228 

* Section 21.3, "Configuring and Administering Security," on page 231 
* Section 21.4, "Links to Product Security Considerations," on page 231 


21.1 Overview of OES Security Services 


This section provides specific overview information for the following key OES components: 


* Section 21.1.1, *Application Security (AppArmor)," on page 227 
* Section 21.1.2, “Auditing,” on page 227 
* Section 21.1.3, “Encryption (NICI)," on page 227 


* Section 21.1.4, *General Security Issues," on page 228 


For more authentication and security topics, see the OES online documentation. 


21.1.1 Application Security (AppArmor) 


Novell? AppArmor? provides easy-to-use application security for both servers and workstations. 
You specify which files a program can read, write, and execute. 


AppArmor enforces good application behavior without relying on attack signatures and prevents 
attacks even if they are exploiting previously unknown vulnerabilities. 


For more information, see the Novell AppArmor Documentation Web site (http://www.novell.com/ 
documentation/apparmor/index.html). 


21.1.2 Auditing 


OES 2 NetWare® includes Nsure™ Audit 1.0.3 Starter Pack, and the applicable documentation is 
included in the OES documentation set. For direct links to the documentation included with OES 2 
NetWare, see the topics in “auditing” in the OES online documentation. 


OES 2 Linux does not include an audit starter pack. However, the Novell Audit 2.0 Starter Pack is 
supported on OES 2 Linux and is available for download at no cost from the Novell Download Site 
(http://www.novell.com/downloads). Documentation for Novell Audit 2.0 is available on the Novell 
Documentation Web site (http://www.novell.com/documentation/novellaudit20/treetitl html). 


21.1.3 Encryption (NICI) 


The Novell International Cryptography Infrastructure (NICI) is the cryptography service for Novell 
eDirectory™, Novell Modular Authentication Services (NMAS™), Novell Certificate Server™, 
Novell SecretStore®, and TLS/SSL. 
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Key Features 
NICI includes the following key features: 


¢ Industry standards: It implements the recognized industry standards. 
¢ Certified: It is FIPS-140-1 certified on selected platforms. 
¢ Cross-platform support: It is available on both OES platforms. 


* Governmental export and import compliance: It has cryptographic interfaces that are 
exportable from the U.S. and importable into other countries with government-imposed 
constraints on the export, import, and use of products that contain embedded cryptographic 
mechanisms. 


* Secure and tamper-resistant architecture: The architecture uses digital signatures to implement 
a self-verification process so that consuming services are assured that NICI has not been 
modified or tampered with when it is initialized. 


Never Delete the NICI Configuration Files 


In the early days of NICI development, some NICI problems could be solved only by deleting the 
NICI configuration files and starting over. The issues that required this were solved years ago, but as 
is often the case, the practice persists, and some administrators attempt to use this as a remedy when 
they encounter a NICI problem. 


No one should ever delete the NICI configuration files unless they are directly told to do so by a 
member of the NICI development team. And in that rare case, they should be sure to back up the 
files before doing so. Failure to do this makes restoring NICI impossible. 


More Information 
For more information on how to use NICI, see the Novell International Cryptographic 


Infrastructure (NICI) 2.7x Administration Guide. 


21.1.4 General Security Issues 


In addition to the information explained and referenced in this section, the OES online 
documentation contains links to “General Security Issues" (http://www.novell.com/documentation/ 
oes2/security.html#b1349evx). 


21.2 Planning for Security 


This section discusses the following topics. For additional planning topics, see the Security section 
in the OES online documentation. 


* Section 21.2.1, “Comparing the Linux and the NetWare Core Protocol (NCP) File Security 
Models,” on page 229 


* Section 21.2.2, "User Restrictions: Some OES 2 Linux Limitations,” on page 230 
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21.2.1 Comparing the Linux and the NetWare Core Protocol 
(NCP) File Security Models 


The NetWare (NSS/NCP™) and Linux (POSIX) security models are quite different, as presented in 


Table 21-1. 


Table 21-1 POSIX vs. NSS/NCP File Security Models 


Feature 


Administrative 
principles 


POSIX / Linux 


Permissions are individually controlled and 
managed for each file and subdirectory. 


Because of the nature of the POSIX 
security model, users usually have read 
rights to most of the system. 


To make directories and files private, 
permissions must be removed. 


For more information on making existing 
directories private, see Section 17.4.2, 
“Providing a Private Work Directory,” on 
page 208. 


NSS/NCP on OES 2 Linux 


Trustee assignments are made to 
directories and files and flow 
down from directories to 
everything below unless 
specifically reassigned. 





Default accessibility 


Users have permissions to see most of the 
file system. 


The contents of a few directories, such as 
the /root home directory, can only be 
viewed by the root user. 


Some system configuration files can be 
read by everyone, but the most critical files, 
such as /etc/fstab, can only be read 
and modified by root. 


Users can see only the 
directories and files for which 
they are trustees (or members of 
a group that is a trustee). 





Home directories—an 
example of default 
accessibility 


By default, all users can see the names of 
directories and files in home directories. 


During LUM installation, you can specify 
that newly created home directories will be 
private. 


For more information on making existing 
home directories private, see 

Section 17.4.2, “Providing a Private Work 
Directory,” on page 208. 


By default, only the system 
administrator and the home 
directory owner can see a home 
directory. Files in the directory are 
secure. 


If users want to share files with 
others, they can grant trustee 
assignments to the individual 
files, or they can create a shared 
subdirectory and assign trustees 
to it. 





Inheritance from 
parents 


Nothing is inherited. 


Granting permission to a directory or file 
affects only the directory or file. 


Rights are inherited in all child 
subdirectories and files unless 
specifically reassigned. 


A trustee assignment can 
potentially give a user rights toa 
large number of subdirectories 
and files. 
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Feature POSIX / Linux NSS/NCP on OES 2 Linux 


Privacy Because users have permissions to see Directories and files are private 
most of the file system for reasons stated by default. 
above, most directories and files are only 
private when you make them private. 





Subdirectory and file Permissions granted to a file or directory When users are given a trustee 


visibility apply to only the file or directory. Users assignment to a file or directory, 
can't see parent directories along the path they can automatically see each 
up to the root unless permissions are parent directory along the path up 
granted (by setting the UID, GID, and mode to the root. However, users can't 
bits) for each parent. see the contents of those 


NE directories, just the path to where 
After permissions are granted, users can they have rights. 


see the entire contents (subdirectories and 
files) of each directory in the path. 


When an NCP volume is created on a Linux POSIX or NSS volume, some of the behavior described 
above is modified. For more information, see the OES 2 SP2: NCP Server for Linux Administration 
Guide, particularly the *NCP on Linux Security" section. 


21.2.2 User Restrictions: Some OES 2 Linux Limitations 


Seasoned NetWare administrators are accustomed to being able to set the following access 
restrictions on users: 


* Account balance restrictions 


* 


Address restrictions 


* 


Intruder lockout 
* Login restrictions 
* Password restrictions 
* Time restrictions 
Many of the management interfaces that set these restrictions (iManager, for example), might seem 


to imply that these restrictions apply to users who are accessing an OES 2 server through any 
protocol. 


This is generally true, with two important exceptions: 


* Maximum number of concurrent connections in login restrictions 
* Address restrictions 
These two specific restrictions are enforced only for users who are accessing the server through 


NCP. Connections through other access protocols (for example, HTTP or CIFS) have no concurrent 
connection or address restrictions imposed. 


For this reason, you probably want to consider not enabling services such as SSH and FTP for LUM 
when setting up Linux User Management. For more information on SSH and LUM, see 
Section 11.4, “SSH Services on OES 2 Linux,” on page 96. 
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For more information on Linux User Management, see “Linux User Management: Access to Linux 
for eDirectory Users” on page 153. For more information on the services that can be PAM-enabled, 


see Table 15-2 on page 156. 


21.3 Configuring and Administering Security 


For a list of configuration and administration topics, see the Security section in the OES online 


documentation. 


21.4 Links to Product Security Considerations 


The following product documentation contains additional security information: 


Table 21-2 Security Consideration Links 


Product/Technology 


Archive and Version Services 


Dynamic Storage Technology 


eDirectory 


File Systems 


Identity Manager 3.5 


Security Considerations Section Link 


"Security Considerations for Archive and Version 
Services" in the NW 6.5 SP8: Novell Archive and 
Version Services 2.1 Administration Guide 


"Security Considerations for Archive and Version 
Services" in the OES 2 SP2: Novell Archive and 
Version Services 2.1 for Linux Administration Guide 


"Security Considerations" in the OES 2 SP2: 
Dynamic Storage Technology Administration Guide 


"Security Considerations" in the Novell eDirectory 
8.8 Administration Guide 


NW 6.5 SP8: File Systems Management Guide 
(information throughout the guide) 


"Security Best Practices (http://www.novell.com/ 
documentation/idm36/idm security/data/ 
front.html)" in the Identity Manager 3.6 
Documentation (http://www.novell.com/ 
documentation/caribou/index.html) 





iPrint for OES 2 Linux 


“Setting Up a Secure Printing Environment’ in the 
OES 2 SP2: iPrint for Linux Administration Guide 





iPrint for OES 2 NetWare 


“Setting Up a Secure Printing Environment” in the 
NW 6.5 SP8: iPrint Administration Guide 





iSCSI for OES 2 NetWare 


Enabling and Configuring iSCSI Initiator Security in 
the NW 6.5 SP8: iSCSI 1.1.3 Administration Guide 





Linux User Management 


“Security Considerations” in the OES 2 SP2: Novell 
Linux User Management Technology Guide 





Native File Access Protocols 


“Enabling and Disabling SMB Signing" in the NW 
6.5 SP8: AFP, CIFS, and NFS (NFAP) 
Administration Guide. 





Novell AFP 


“Security Guidelines for AFP” in the OES 2 SP2: 
Novell AFP For Linux Administration Guide 
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Product/Technology 


Novell CIFS 


Security Considerations Section Link 


“Security Guidelines for CIFS” in the OES 2 SP2: 
Novell CIFS for Linux Administration Guide. 





Novell Client™ for Windows 


"Managing File Security and Passwords" in the 
Novell Client 4.91 SP5 for Windows XP/2003 
Installation and Administration Guide 





Novell Client for Linux 


"Managing File Security" in the Novell Client 2.0 
SP2 for Linux Administration Guide 





Novell Remote Manager for OES 2 Linux 


"Security Considerations" in the OES 2 SP2: Novell 
Remote Manager for Linux Administration Guide 





Novell Remote Manager for OES 2 NetWare 


Novell Storage Services 


"Security Considerations" in the NW 6.5 SP8: 
Novell Remote Manager Administration Guide 


"Securing Access to NSS Volumes, Directories, 
and Files" and "Security Considerations" in the NW 
6.5 SP8: NSS File System Administration Guide 





Novell iFolder® 3.7 or later 


OES 2 Linux Installation 


Novell iFolder 3.8 Security Administration Guide 


"Security Considerations" in the OES 2 SP2: 
Installation Guide 





OES 2 Migration Tools 


"Security Considerations for Data Migration" in the 
OES 2 SP2: Migration Tool Administration Guide 








OpenWBEM "Ensuring Secure Access" in the NW 6.5 SP8: 
OpenWBEM Services Administration Guide 
QuickFinder™ “Security Considerations for QuickFinder Server” in 


the QuickFinder Server 4.0 Administration Guide 





Server Consolidation and Migration Toolkit 
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“Security Considerations” in the Novell Server 
Consolidation and Migration Toolkit Administration 
Guide 


Certificate Management 


By default, all SUSE® Linux Enterprise Server (SLES) 10 servers include self-generated server 
certificates to secure data communications with the servers. These certificates are self-signed and do 
not comply with the X.509 RFCs. They are provided only as a stop-gap and should be replaced as 
soon as possible by a certificate from a trusted Certificate Authority. 


Unfortunately, many organizations ignore the vulnerabilities to mischievous or even malicious 
attacks that are created by not replacing these temporary certificates. Some of the reasons for this are 


* Many administrators lack the knowledge required. 
* Certificate maintenance can require a significant investment of time and effort. 


* Obtaining third-party certificates for each server is expensive. 


The problems are compounded by the fact that X.509 certificates are designed to expire regularly 
and should be replaced shortly before they do. 


Open Enterprise Server 2 includes solutions that address each of these issues at no additional 
expense. 


This section discusses the certificate management enhancements available in OES 2 and how simple 
and straightforward it is to take advantage of these. 


* Section 22.1, "Overview," on page 233 
* Section 22.2, "Setting Up Certificate Management," on page 236 
* Section 22.3, "If You Don't Want to Use eDirectory Certificates," on page 238 


22.1 Overview 


The following sections outline how OES 2 lets you automate certificate management for OES 2 and 
all HTTPS services: 


* Section 22.1.1, "SLES Default Certificates," on page 233 
* Section 22.1.2, *OES 2 Certificate Management," on page 234 
* Section 22.1.3, “Multiple Trees Sharing a Common Root,” on page 236 


22.1.1 SLES Default Certificates 


By default, HTTPS services on SLES 10 SP1 are configured to use two files that are located in / 
etc/ssl/servercerts and are protected so that only root and some specific groups can read 
them: 


* serverkey.pem: This contains the server's raw private key. 
y: p y. 


* servercert.pem: This contains the server's certificates. 


OES 2 services, such as Apache, OpenWBEM, and Novell Remote Manager, are also configured to 
use these certificates. 
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22.1.2 OES 2 Certificate Management 


OES 2 enhances certificate management as follows: 


* “Installation of eDirectory Certificates" on page 234 
* “What Is Installed Where" on page 234 

* “Novell Certificate Server" on page 235 

* "Server Self-Provisioning" on page 235 

* "PKI Health Check" on page 235 


Installation of eDirectory Certificates 


As you install eDirectory'" and OES 2, by default all HTTPS services are configured to use 
eDirectory certificates. This means that eDirectory is established as the Certificate Authority for the 
tree you are installing into, and it will generate keys and certificates for the server and replace the 
installed SLES certificates with the eDirectory certificates. 


What Is Installed Where 


Key and certificate files are installed in the following locations: 
Table 22-1 File Locations 


Location Details 


/etc/ssl/certs This is the default location of trusted root certificates for clients 
on the server. 


Most of the applications on the server are configured to use 
this directory. For example, the LDAP client uses one or more 
of the trusted certificates in this directory when establishing a 
secure LDAP connection. 


The OES 2 installation copies the eDirectory tree CA's 
certificate (eDirCACert . pem) here, thereby establishing the 
CA as a trusted root. 


Everyone (other) has rights to read the contents of this 
directory. 


/etc/ssl/servercerts The standard location for the server's raw private key 
(serverkey.pem) and certificates (servercert.pem). 


Applications on the server, including OES 2 applications, are 
configured to point to the files in this directory. 


Only root and some specific groups can read the files in this 
directory. 
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Location Details 


/etc/opt/novell/certs This directory contains the eDirectory CA certificate in both 
DER and PEM formats for use by applications that need them. 
The files are named SSCert.der and SSCert.pem, 
respectively. 


For example, when PKI Health Check runs, it installs the CA 
certificate in the Java Keystore in DER format if the certificate 
needs replacing. 


Novell Certificate Server 
The component that generates eDirectory keys and certificates is the Novell Certificate Server™. 


This certificate server provides public key cryptography services that are natively integrated into 
Novell eDirectory. You use the server to can mint, issue, and manage both user and server 
certificates to protect confidential data transmissions over public communications channels such as 
the Internet. 


For complete information on the Novell Certificate Server, see the Novell Certificate Server 3.3 
Administration Guide. 


Server Self-Provisioning 


When activated, Server Self-Provisioning lets server objects in eDirectory create their own 
certificates. You must activate this option if you want PKI Health Check to automatically maintain 
your server certificates. 


For more information on this feature, see “X.509 Certificate Self-Provisioning" in the Novell 
Certificate Server 3.3 Administration Guide. 


PKI Health Check 
The PKI health check runs whenever the certificate server starts. 


If you have enabled Server Self-Provisioning, the health check routine automatically replaces server 
certificates when any of the following are detected: 

* The certificates don't exist. 

* The certificates have expired. 

+ The certificates are about to expire. 

* The IP or DNS information on the certificates doesn't match the server configuration. 

* The Certificate Authority (CA) that issued the certificate is different from the CA currently 


configured. 


For more information on this feature, see “PKI Health Check" in the Novell Certificate Server 3.3 
Administration Guide. 
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22.1.3 Multiple Trees Sharing a Common Root 


The Organizational CA can be configured to act as a sub-CA. This lets multiple trees share a 
common root certificate. The root certificate can be stored in a physically protected tree. It can also 
integrate with a third-party PKI. For more information, see “Subordinate Certificate Authority” in 
the Novell Certificate Server 3.3 Administration Guide. 


22.2 Setting Up Certificate Management 


Use the information in the following sections to help you set up certificate management as you 
install OES 2. 
¢ Section 22.2.1, “Setting Up Automatic Certificate Maintenance,” on page 236 


* Section 22.2.2, “Eliminating Browser Certificate Errors,” on page 236 


22.2.1 Setting Up Automatic Certificate Maintenance 


To set up your server so that HTTPS services use eDirectory certificates, you must specify the Use 
eDirectory Certificates for HTTP Services option while installing or upgrading eDirectory. 


This installs eDirectory keys and certificates on the server, but it does not configure the server to 
automatically replace the certificates when they expire. Automatic maintenance requires that Server 
Self-Provisioning be enabled as follows: 


1 On the server you are configuring, in iManager > Roles and Tasks, click the Novell Certificate 
Access > Configure Certificate Authority option. 
2 Click Enable server self-provisioning. 


This causes automatic certificate replacement for the conditions described in ^PKI Health 
Check" on page 235. 





IMPORTANT: If you enable Server Self-Provisioning in an OES 2 tree and you have created a 
CRL configuration object but not yet configured any CRL distribution points, the PKI Health 
Check might replace the default certificates every time it runs. 


To avoid this, you can either 


*Finish configuring the CA's CRL capability by creating one or more CRL Distribution Points 
by using iManager's Configure Certificate Authority task. 


or 


Delete any CRL Configuration objects, for example CN=One - Configuration. CN=CRL 
Container.CN=Security. 





3 Ifyou also want the CA certificate to be replaced if it changes or expires, click the Health 
Check - Force default certificate creation/update on CA change option. 


22.2.2 Eliminating Browser Certificate Errors 


Because the Internet Explorer and Mozilla Firefox* browsers don’t trust eDirectory certificate 
authorities by default, attempts to establish a secure connection with OES 2 servers often generate 
certificate errors or warnings. 


These are eliminated by importing the eDirectory tree CA’s self-signed certificate into the browsers. 
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Complete the instructions in the following sections as applicable to your network. 


* “Exporting the CA's Self-Signed Certificate" on page 237 

+ “Importing the CA Certificate into Mozilla Firefox on Linux" on page 237 

* "Importing the CA Certificate into Mozilla Firefox on Windows" on page 237 

+ “Importing the CA Certificate into Internet Explorer 6 and 7 on Windows" on page 238 


Exporting the CA's Self-Signed Certificate 


1 Launch Novell iManager. 
2 Log into the eDirectory tree as the Admin user. 


3 Select the Roles and Tasks menu, then click Novell Certificate Server > Configure Certificate 
Authority. 


4 Click the Certificates tab, then select the self-signed certificate. 
5 Click Export. 
6 Deselect Export Private Key. 
The Export Format changes to DER. 
7 Click Next. 


8 Click Save the Exported Certificate and save the file to the local disk, noting the filename and 
location if they are indicated. 


9 Click Close > OK. 
10 Find the file you just saved. By default it is usually on the desktop. 


11 Complete the instructions in the follow sections that apply to your browsers. 


Importing the CA Certificate into Mozilla Firefox on Linux 


Launch Firefox. 

Click Edit > Preferences > Advanced. 
Select the Encryption tab. 

Click View Certificates. 

Select the Authorities tab, then click Import. 
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Browse to the certificate file you downloaded in “Exporting the CA’s Self-Signed Certificate” 
on page 237 and click Open. 


7 Select Trust this CA to identify Web sites, then click OK > OK > Close. 


Firefox now trusts certificates from the servers in the tree. 


Importing the CA Certificate into Mozilla Firefox on Windows 


1 Launch Firefox. 

2 Click Tools > Options > Advanced. 

3 Select the Security tab. 

4 Click View Certificates. 

5 Select the Authorities tab, then click Import. 
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6 Browse to the certificate file you downloaded in “Exporting the CA’s Self-Signed Certificate” 
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on page 237 and click Open. 
Select Trust this CA to identify Web sites, then click OK > OK > OK. 


Firefox now trusts certificates from the servers in the tree. 


Importing the CA Certificate into Internet Explorer 6 and 7 on Windows 
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Launch Internet Explorer. 

Click Tools > Internet Options. 

Select the Content tab. 

Click Certificates. 

Click Import. 

The Certificate Import Wizard launches. 
Click Next. 


Click Browse, 


8 In the Files of Type drop-down list, select All Files(*.*), browse to the file you downloaded in 


“Exporting the CA’s Self-Signed Certificate” on page 237, then click Open. 


9 Click Next. 
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Click Next. 
Choose the default, Automatically select the certificate store based on the type of certificate. 
Click Finish > Yes > OK. 


Internet Explorer now trusts certificates from the servers in the tree. 


22.3 If You Don’t Want to Use eDirectory 
Certificates 


For most organizations, the eDirectory certificate solution in OES 2 is an ideal way to eliminate the 
security vulnerabilities mentioned at the beginning of this chapter. However, some administrators, 
such as those who have third-party keys installed on their servers, probably want to keep their 
installed certificates in place. 


You can prevent the use of eDirectory certificates for HTTPS services by making sure that the 
option to use them is not selected on the first eDirectory configuration page. This might or might not 
require that you change the eDirectory installation option, depending on your scenario. 


Table 22-2 outlines the default setting for each scenario. 


Table 22-2 Default eDirectory Certificate for HTTPS Settings 


Certificate Option 


Scenario Setting Default Result If you Change the Default Setting 

New install Selected All HTTPS services on the All HTTPS services on the server 
server are configured to use are configured to use the YaST- 
eDirectory certificates. generated tempoary certificates. 
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Scenario 


Add-on to 
SLES 10 or 
post-install 


Upgrade from 
OES 1 


Upgrade from 
OES 2 


Certificate Option 
Setting 


Selected 


Selected 


The same option is 
used as when OES 
2 was installed 


Default Result 


All HTTPS services on the 
server are configured to use 
eDirectory certificates. 


All HTTPS services are 
configured to use eDirectory 
certificates. 


HTTPS service settings are 
retained. 


If you Change the Default Setting 


The current service certificates 
and configurations are retained. 


The current service certificates 
and configurations are retained. 


No effect. 


Once the option to use 
eDirectory certificates has been 
used, the behavior can only be 
changed in eDirectory through 
iManager. 
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Adding Services to OES 2 Servers 


You can add services to Open Enterprise Server 2 servers after they are installed. 


OES 2 Linux 


OES 2 Linux is a set of services that can be either added to an existing server or installed at the same 
time as SUSE® Linux Enterprise Server 10 SP1. After OES 2 services are added, we refer to the 
server as an OES 2 Linux server. 


To add OES 2 Linux services to an OES 2 Linux server, follow the instructions in “Installing/ 
Configuring OES 2 SP2 on an Existing Server” in the OES 2 SP2: Installation Guide. 


OES 2 NetWare 


Some products, such as Novell® Cluster Services™, can be installed only after completing the server 
installation. 


You can install additional products by using Novell Deployment Manager (remotely) or from the 
GUI server console page (locally). For more information, see “Installing Additional Products” in the 
NW65 SP8: Installation Guide. 
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Changing an OES 2 Linux Server’s 
IP Address 


The instructions in this section let you change the IP address assigned to an Open Enterprise Server 
2 or OES 2 SPI Linux server and the services it hosts. 

* Section B.1, “Caveats and Disclaimers,” on page 243 

* Section B2, “Prerequisites,” on page 243 

* Section B.3, “Changing the Server’s Address Configuration," on page 244 

* Section B.4, "Reconfiguring the OES Services," on page 244 

¢ Section B.5, “Repairing the eDirectory Certificates," on page 245 

* Section B.6, "Completing the Server Reconfiguration," on page 245 

* Section B.7, “Modifying a Cluster,” on page 247 


* Section B.8, “Reconfiguring Services on Other Servers That Point to This Server," on page 247 


B.1 Caveats and Disclaimers 


The instructions in this section assume that only the IP address of the server is changing. They do 
not cover changing the DNS hostname of the server. 


B.2 Prerequisites 


* Section B.2.1, “General,” on page 243 
* Section B.2.2, “iPrint,” on page 244 
* Section B.2.3, "Clustering," on page 244 


B.2.1 General 


Before starting the process, be sure you know the following: 


L) Old IP Address: The server's IP address you are changing. 
Q New IP Address: The IP address the server will use after the change. 


Q Old Master Server Address: The IP address of the eDirectory™ server specified when the 
server was installed. 





By default this is also the LDAP server address for OES services installed on the server. 


Q New Master Server Address: The IP address of the eDirectory server that the server should 
point to after the change. The old and new addresses might be the same, but you will be 
required to enter both. 

O Address of the Subnet for the New IP Address: This is a subnet address, not the subnet 
mask. For example, 192.168.2.0, not 255.255.255.0. 
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B.2.2 iPrint 


If your network users connect to their printers through the print manager on this server, you might 
want to consider setting up iPrint Client Management (ICM) prior to the change. ICM lets you 
centrally configure the iPrint configuration for your users. For more information, see “Using iPrint 
Client Management” in the OES 2 SP2: iPrint for Linux Administration Guide. 


B.2.3 Clustering 


If the server is running Novell Cluster Services: 
1 Check your plans against the prerequisites for clusters in “Configuration Requirements” in the 
OES 2 SP2: Novell Cluster Services 1.8.7 for Linux Administration Guide. 


2 Follow the instructions in “Changing the IP Addresses of Cluster Resources” in the same 
guide. 


B.3 Changing the Server’s Address 
Configuration 


1 Log into the server you are reconfiguring as the root user. 


2 Download and save the ipchangesp1.sh script file (http://www.novell.com/documentation/ 
oes2/scripts/ipchangesp1.sh) to the root (/) partition of the server you are reconfiguring. 


The same script file works on both OES 2 and OES 2 SPI servers. 
3 Open the YaST Control Center. 
4 In Network Devices select Network Card. 


5 Confirm that the Old IP address you listed in Section B.2.1, “General,” on page 243 is in fact 
the IP address currently configured for the network card. You need this later in the process. 


6 Using the various dialog boxes associated with the network card configuration, change the card 
configuration to the new IP address settings you listed in Section B.2.1, General," on 
page 243, changing each of the following as necessary: 


* IP Address 
* Subnet Mask 
* Router (Gateway) 
7 Close YaST, then continue with Section B.4, *Reconfiguring the OES Services," on page 244. 


B.4 Reconfiguring the OES Services 


1 Open a terminal prompt. 


2 At the terminal prompt, change to the root (/) directory, make the script executable, then run the 
script by entering the following commands: 


cd / 
chmod 744 ipchangespl.sh 


./ipchangespl.sh oldip newip oldmasterip newmasterip 


244 NW 6.5 SP8: Planning and Implementation Guide 


where oldip is the old IP address, newip is the new IP address, o/dmasterip is the IP address of 
the eDirectory server specified when the server was installed, and newmasterip 1s the IP 
address of the new eDirectory server identified in Prerequisites above. 


The oldmasterip and the newmasterip can be the same IP address, but they must both be 
included in the command. 





IMPORTANT: By default, the master eDirectory address is also the LDAP server address for 
OES services installed on the server. 


All services that are configured with the old master address as their LDAP address are 
reconfigured to use the new master address. On the other hand, if you specified a different 
LDAP server address for any of the installed services, and if that LDAP server’s address is also 
changing, you need to manually reconfigure the services . 


To see the IP addresses that your services were originally configured to use, use a text editor to 
open the files in /etc/sysconfig/novell/. 





As the script runs, it changes all of the OES configuration files and does everything else that 
can be done automatically to change the IP address for all OES services. 


3 Type the Admin password when prompted. 
You might need to wait a few minutes for the LDAP server to restart. 


4 When the script finishes, restart the server by entering the following command at the terminal 
prompt: 


shutdown -r now 


B.5 Repairing the eDirectory Certificates 


1 Start iManager and click through the warnings about a DNS name mismatch. 


2 Inthe Login dialog box, type the Admin username and password, type the newmasterip address 
in the 7ree field, then click Login. 


3 Click Novell Certificate Server > Repair Default Certificates. 


4 In Create Server Certificate > Step 1 of 3, browse to and select the server object for the server 
you are changing. 


5 Click OK > Next. 
6 In Step 2 of 3, click Next. 
7 Click Finish, then close the dialog box. 


B.6 Completing the Server Reconfiguration 


Some OES services require reconfiguration steps to be done manually. 
Complete the steps in the following sections as they apply to the server you are changing. 


* Section B.6.1, “QuickFinder,” on page 246 
* Section B.6.2, “DHCP,” on page 246 

* Section B.6.3, “iPrint,” on page 246 

* Section B.6.4, “NetStorage,” on page 246 
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B.6.1 QuickFinder 


1 Ifthe IP address you have changed is listed as an alias for the virtual search server, modify the 
list by deleting the entry for the old address and adding an entry for the new one. 


For instructions, see “Deleting a Virtual Search Server" and “Creating a Virtual Search Server" 
in the NW 6.5 SP8 Novell QuickFinder Server 5.0 Administration Guide. 


2 Regenerate the QuickFinder™ index by completing the instructions in see “Creating Indexes” 
in the NW 6.5 SP8 Novell QuickFinder Server 5.0 Administration Guide. 


B.6.2 DHCP 


1 Make sure the DHCP configuration in eDirectory has a subnet declared for the new IP address. 


For instructions, see “Administering and Managing DHCP” in the OES 2 SP2: Novell DNS/ 
DHCP Administration Guide for Linux. 


B.6.3 iPrint 


1 Using your favorite text editor, open the following configuration file: 
/etc/opt/novell/iprint/conf/DN of PSMipsmd.conf 
where DN of PSM is the name of the Print Manager in eDirectory. 

2 Change any entries that list the old IP address to the new IP address. 

3 Restart the Print Manager by entering the following command at a terminal prompt: 


rcnovell-ipsmd restart 





IMPORTANT: Users that have accessed printers through the modified Print Manager will lose 
access to their printers. 


If you have set up iPrint Client Management on the server, you can automate the 
reconfiguration process. If not, users must reinstall the printers. 


For more information on iPrint Client Management, see “Using iPrint Client Management” in 
the OES 2 SP2: iPrint for Linux Administration Guide. 


B.6.4 NetStorage 


1 Ata terminal prompt, enter the following commands: 


/opt/novell/xtier/bin/xsrvcfg -D 
/opt/novell/xtier/bin/xsrvcfg -d newip -c AuthenticationContext 


where newip is the new IP address used throughout this section and AuthenticationContext is 
the eDirectory context for NetStorage users. NetStorage searches the eDirectory tree down 
from this container. If you want NetStorage to search the entire eDirectory tree, specify the 
root context. 


rcnovell-xregd restart 
rcnovell-xsrvd restart 


rcapache2 restart 
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B.7 Modifying a Cluster 


If the server is running Novell Cluster Services™, complete the instructions in “Modifying the 
Cluster Configuration Information” in the the OES 2 SP2: Novell Cluster Services 1.8.7 for Linux 
Administration Guide. 


B.8 Reconfiguring Services on Other Servers 
That Point to This Server 


If you have services on other servers that point to the old IP address for this server, be sure to 
reconfigure those services to point to the new IP address. 
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Updating/Patching OES 2 Servers 


One of a network administrator’s biggest challenges is keeping installed software up-to-date on all 
servers and workstations. 


Patching OES 2 Linux 


You can install product updates as they are made available through the ZENworks” Linux 
Management update channel. For instructions on setting up the ZENworks Linux Management 
update channel for each OES 2 Linux server and running the patch process, see “Updating 
(Patching) an OES 2 SP2 Server" in the OES 2 SP2: Installation Guide. 


Patching OES 2 NetWare 


For best reliability and performance, you should download and install the latest product updates 
available at the Novell® Downloads site (http://download.novell.com). 
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Backup Services 


The following sections briefly outline the backup services available in Open Enterprise Server 2. For 
more information, see the topics listed under “Backup” in the OES 2 online documentation. 
* Section D.1, “Services for End Users,” on page 251 


* Section D.2, “System-Wide Services," on page 251 


D.1 Services for End Users 


OES 2 offers a number of services to automatically back up your network users’ data files. 


* Archive and Version Services: If you implement Archive and Version Services on your 
network, your users can instantly restore any previous version of a modified, renamed, or 
deleted network file on an NSS volume without requiring assistance from the IT staff. 


¢ iFolder 3.7: By implementing Novell® iFolder® 3.7, you empower your users to have their 
local files automatically follow them everywhere—online, offline, all the time—across 
computers. Users can share files in multiple iFolders, and share each iFolder with a different 
group of users. Users control who can participate in an iFolder and their access rights to the 
files in it. Users can also participate in iFolders that others share with them. 


* Salvage and Purge: By default, all NSS volumes have the Salvage system enabled at the time 
they are created. With Salvage enabled, deleted files are retained on the volume for a short 
time, during which users can restore (salvage) them. File are eventually purged from the 
system, either manually, or by the system when the Purge Delay setting times out or space is 
needed on the volume. 


D.2 System-Wide Services 


OES 2 offers both Novell Storage Management Services!" and services that are available as part of 
the SUSE? Linux Enterprise Server 10 distribution. 


* Section D.2.1, “Novell Storage Management Services (SMS)," on page 251 
* Section D.2.2, "SLES 10 Backup Services," on page 252 


D.2.1 Novell Storage Management Services (SMS) 


* "Understanding SMS" on page 251 


* "SMS Coexistence and Migration Issues" on page 252 


Understanding SMS 


Novell Storage Management Services (SMS) is not a backup application. Rather, it provides a 
standard framework and the necessary interfaces that can be used in developing a complete backup/ 
restore solution. SMS helps back up file systems (such as NSS) on OES 2 NetWare? and OES 2 
Linux servers to removable tape media or other media for offsite storage. 
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SMS is implemented as two independent components that provide functional abstractions: 


* Storage Management Data Requestor (SMDR) defines the API framework, provides remote 
connectivity, and abstracts the details of communication between servers. 


¢ Target Service Agent (TSA) provides an implementation of SMS APIs for a particular target. 
The TSA provides transparency by abstracting details of the specific service being backed up. 


For example, various applications use the file system TSA to back up and restore NSS file 
system data and metadata (trustee assignments, file attributes, and name spaces). 


SMS Coexistence and Migration Issues 


In OES 2, the SMS API framework is available on SLES 10 so that there is a single consistent 
interface to back up file systems on NetWare, file systems on Linux, and Novell applications such as 
Group Wise® and Novell iFolder. The API set has been enhanced to include new functionality for 
OES. 


Most of the SMS coexistence and migration issues are of concern only to backup application 
developers. However, administrators should be aware that SMS-based applications must be used to 
back up and restore NSS file system data on OES Linux servers. Although NSS is exposed as a 
Virtual File System-compliant file system, the Linux interfaces are inadequate to back up NSS file 
system attributes, rich ACLs, trustees, and multiple data streams. 


For additional information, see “Coexistence and Migration Issues” in the NW 6.5 SP8: Storage 
Management Services Administration Guide. 


D.2.2 SLES 10 Backup Services 


Two SLES 10 services might be of interest. 


* DRDB: This lets you to create a mirror of two block devices at two different sites across an IP 
network. When used with HeartBeat 2 (HB2), DRBD supports distributed high-availability 
Linux clusters. For more information, see “Installing and Managing DRBD Services” (http:// 
www.novell.com/documentation/sles10/stor_evms/data/drdb.html) in the SLES 10 SP2: 
Storage Administration Guide (http://www.novell.com/documentation/sles 10/stor_evms/data/ 
bookinfo.html). 


¢ rsyne: This is useful when large amounts of data need to be backed up regularly or moved to 
another server, such as from a staging server to a Web server in a DMZ. For more information, 
see “Introduction to rsync” (http://www.novell.com/documentation/sles10/sles_admin/data/ 
sec net sync rsync.html) in the SLES 10 SP2: Installation and Administration Guide (http:// 
www.novell.com/documentation/sles10/sles admin/data/sles admin.html). 
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Quick Reference to OES 2 User 
Services 


Use Table E-1 as a quick reference for providing your network users with instructions for accessing 
each Novell® Open Enterprise Server 2 service. 


Table E-1 OES User Services Quick Reference 






































services Access Method or URL Notes 
iPrint http://server ip address or dns name/ipp 
https://server ip address or dns name:443/ipp 
Native File Use the standard file managers on a Linux, Macintosh, NFAP is installed and available 
Access Windows, or UNIX workstation to access volumes on by default on all NetWare 
Protocols OES 2 NetWare that you have the appropriate file servers. 
(NFAP) trustee rights to. 
NetStorage For browser access, use: The WebDAV URL is case 
sensitive. 
http: or https://server ip or dns/netstorage 
For WebDAV access, use: 
http: or https://server ip or dnsloneNet/NetStorage 
Novell 1. Install the Novell Client on a supported Windows 
Client™ workstation. 
2. Log in to eDirectory™. 
3. Access NCP™ volumes on NetWare or Linux that you 
have the appropriate file trustee rights to. 
Novell AFP In the Chooser, click Go and browse to the server. 
Novell CIFS Map a network drive in Windows Explorer. 
Create a Web Folder in Internet Explorer. 
Novell https://server ip address or dns namelifolder "ifolder" is the default name, but 
iFolder? 3.x this can be customized by the 
Web administrator. 
Access 
Server 
Novell http://server ip address or dns name:8008 Any LUM-enabled user can see 
Remote their directories and files on 
Manager OES 2 Linux servers. 
Samba Map a network drive in Windows Explorer. 


Create a Web Folder in Internet Explorer. 
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OES 2 SP1 Browser Support 


As a general rule, Open Enterprise Server 2 SP1 management tools support the following browsers 
as they are available on the workstation platforms listed in “Client/Workstation OS Support” on 
page 257: 

* Mozilla Firefox2.0.x 

* Microsoft Internet Explorer 6 (latest SP) 

* Microsoft Internet Explorer 7 (latest SP) 

* Apple Safari* 3.1 


Table F-1 provides service-specific links and information about browser support in Novell? OES. 
Table F-1 Browser Support in OES 


Management Tool Supported Browser Information Link 


iManager 2.7 * "Using a Supported Web Browser' in the Novell iManager 2.7.3 
Administration Guide 


There are rendering differences for some iManager plug-ins between 
Internet Explorer 6 (IE) and Mozilla-based browsers. For example, 
options that are accessed through tabs in IE are sometimes accessed 
through drop-down lists in Firefox. 





iMonitor * "System Requirements" in "Using Novell iMonitor 2.4" in the 
Novell eDirectory 8.8 Administration Guide 





IP Address Manager (NetWare®) Same as Novell Remote Manager 





iPrint * "Supported Browsers for iPrint" in the OES 2 SP2: iPrint for 
Linux Administration Guide 


+ “Supported Browsers for iPrint" in the NW 6.5 SP8: iPrint 
Administration Guide 











MySQL 4.0 (phpMyAdmin) + “Administering MySQL Using phpMyAdmin" in the NW 6.5 SP8: 
(NetWare) Novell MySQL Administration Guide 

Novell iFolder® 3.7 * "Web Browser' in the Novell iFolder 3.8 Administration Guide 
Novell Remote Manager * "System Requirements" in the OES 2 SP2: Novell Remote 


Manager for Linux Administration Guide 


* "System Requirements" in the NW 6.5 SP8: Novell Remote 
Manager Administration Guide 





OpenSSH Manager (NetWare) * “Added Functionality” in the NW 6.5 SP8: OpenSSH 
Administration Guide 





QuickFinder™ Server Manager * "Managing QuickFinder Server” in the NW 6.5 SP8 Novell 
QuickFinder Server 5.0 Administration Guide 





TCP/IP Configuration (NetWare) Same as Novell Remote Manager 
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Management Tool Supported Browser Information Link 


Tomcat Manager * "Managing Tomcat with Tomcat Admin" in the NW 6.5 SP8: 
Tomcat Administration Guide 
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Client/Workstation OS Support 


As a general rule, Open Enterprise Server 2 services can be accessed and administered from 
workstations running the following operating systems: 

* SUSE® Linux Enterprise Desktop 10 SP2 

* Microsoft Windows XP SP2 and SP3 

* Microsoft Windows Vista Business SP1 

+ Microsoft Windows Vista Business 64-bit SP1 

* Microsoft Windows Vista Ultimate SPI 

* Microsoft Windows Vista Ultimate 64-bit SP1 

+ Microsoft Windows Vista Enterprise SP1 

* Microsoft Windows Vista Enterprise 64-bit SP1 

* Macintosh OS X 10.4 Tiger* (Intel*) (non-administrative only) 

* Macintosh OS X 10.5 Leopard* (Intel) (non-administrative only) 

* Windows 2000 SP4 Server (iPrint Client only) 

+ Windows 2003 Server (iPrint Client only) 

+ Windows 2008 Server (iPrint Client only) 





For specific information on a given service, consult the service documentation. 
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OES 2 Linux Service Scripts 


Novell® Open Enterprise Server 2 services rely on specific service scripts located in /etc/init.d. 
The scripts used by OES 2, some of which are standard Linux scripts, are listed in Table H-1. 





IMPORTANT: For managing OES 2 services, we strongly recommend using the browser-based 
tools outlined in Section 11.1, “Overview of Management Interfaces and Services,” on page 81. The 
browser-based tools provide error checking not available at the service-script level, and they ensure 
that management steps happen in the sequence required to maintain service integrity. 





Table H-1 OES Service Scripts in /etc/init.d 





Services Associated with Scripts Script Name Notes 

Apache Web server apache2 The rcapache2 symbolic link, which is by 
default part of the path, can be used to 
start, stop, and restart the Apache Web 
Server, rather than referencing the init 
script directly. 

Archive and Version Services novell-ark This lets you to start, stop, restart and 
display the status of the Archive and 
Version Service. 

CASA micasad This is the CASA daemon. 

Distributed File Services novell-dfs This lets you start and stop the VLDB 


DNS (Novell eDirectory™ enhanced)  novell-named 


DNS (SUSE® Linux Enterprise Server named 
10 base) 


service. 


This works in connection with named to 
provide Novell eDirectory DNS services. 


This is the SLES 10 DNS service daemon. 














Dynamic Storage Technology novell-shadowfs This script starts and stops the shadowfs 
daemon and the kernel module fuse. 

eDirectory ndsd This lets you start and stop eDirectory. It 
executes the /usr/sbin/ndsd binary. 

eDirectory SNMP support ndssnmpsa 

eDirectory LDAP support nldap This lets you load and unload the LDAP 
library that Novell eDirectory uses to 
provide LDAP support. It is not actually a 
service. 

FTP pure-ftpd This is used by the Novell FTP Pattern. 

iPrint cups 


novell-idsd 


novell-ipsmd 
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Services Associated with Scripts 


iPrint 


Script Name 


cups 


Notes 


iPrint uses this daemon. 





Linux User Management 


namcd 


nscd 


These daemons are required by Linux User 
Management and work together to ensure 
good performance. 


The namcd daemon caches user and group 
names and IDs from eDirectory, speeding 
subsequent lookups of cached users and 
groups. 


The nscd daemon caches host names and 
addresses. 





Logging 


syslog 


This is used for logging by many OES 2 
services. 





Novell AFP 


novell-afptcpd 


This script starts and stops the afptcpd 
daemon, which is the Novell AFP service 
daemon 





Novell CIFS 


novell-cifs 


This script starts and stops the cifsd 
daemon, which is the Novell CIFS service 
daemon 





NetStorage (actually XTier) 


novell-xregd 


novell-xsrvd 


NetStorage runs inside the novell-xsrvd 
XTier Web Services daemon, and also 
utilizes Tomcat services for certain other 
functions. 


novell-xregd is the init script for starting and 
stopping XTier’s registry daemon. It is part 
of the novell-xtier-base RPM and is 
enabled by default for run levels 2, 3, and 5. 





novell-xsrvd is the init script for starting and 
stopping XTier’s Web services daemon. It 
is also part of the novell-xtier-web 
RPM and is enabled for run levels 2, 3, and 
5. 





Novell Cluster Services™ (NCS) 


novell-ncs 
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NCS uses some shell scripts and utilities 
that come with the heartbeat package. For 
example, NCS uses a binary called 

send arp to send out ARP packets when a 
secondary address is bound. 


NCS never runs the heartbeat daemons. In 
fact, NCS and heartbeat are mutually 
exclusive when it comes to execution, and 
heartbeat must always be configured to not 
run (chkconfig heartbeat off) when NCS is 
loaded on the server. 


Services Associated with Scripts 


Novell Remote Manager 


Script Name 


novell-httpstkd 


Notes 


This script runs by default on every OES 2 
Linux server and enables access to NRM 
for Linux through a browser. 


Use this script followed by the status option 
to view current status. Or use stop, start, or 
restart options to alter the run state of the 
NRM daemon as needed. 





Novell Storage Services™ 


novell-nss 


This script runs by default on every OES 2 
Linux server with NSS volumes and 
enables access to the NSS runtime 
environment. 


To see if the NSS kernel modules and NSS 
admin volume are running, enter service 
novell-nss status, /etc/init.d/ 
novell-nss status,orrcnovell-nss 
status ata command prompt. If they are 
not running, use the start option to start 
them. You cannot stop NSS. 





Novell Remote Manager e-mail 
notifications 


postfix 


Novell Remote Manager uses this to send 
notifications as configured. 





NTP 


ntp 


This is the SLES 10 Network Time Protocol 
daemon. 





OpenWBEM CIMOM 


owcimomd 


This is used to start the OpenWBEM 
CIMOM daemon, which is an integral part 
of the iManager plug-ins for LUM, Samba, 
NSS, SMS, and NCS. iPrint and NRM also 
use OpenWBEM. 


Novell Remote Manager on OES 2 Linux 
gets its server health information from 
CIMOM. 





Patching 


novell-zmd 


This is the GUI patch updater daemon. 





Red Carpet® 


rcd 


This is the rug command line daemon. 





Samba 


nmb 


This is the Samba NetBIOS naming 
daemon. 





Samba CIFS support 


smb 


This script runs the Samba daemon. 





SLP support 


slpd 


This lets you start and stop OpenSLP, 
which is a key component for eDirectory 
and certain other services and clients. 





Storage Management Services™ 


novell-smdrd 


This lets you start and stop the SMDR 
daemon precess. It also loads and unloads 
the NSS zapi kernel module used by SMS 
to back up the NSS volumes. 





Tomcat 


novell-tomcat5 


This script sets up the SLES 10 Tomcat 
specifically for OES 2 services, such as the 
Welcome pages. 
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System User and Group 
Management in OES 2 SP1 


This section discusses the users and groups that are used by Open Enterprise Server. Administrative 
users are discussed in Appendix J, “Administrative Users in OES 2 SP1,” on page 283. 

¢ Section I.1, “About System Users and Groups,” on page 263 

¢ Section I.2, "Understanding Proxy Users," on page 265 

* Section L3, “Planning Your Proxy Users," on page 270 

¢ Section L4, “Implementing Your Proxy User Plan," on page 277 

* Section I.5, “Proxy Users and Domain Services for Windows," on page 278 

* Section I.6, “System Users," on page 278 

* Section I.7, “System Groups," on page 280 


1.1 About System Users and Groups 


"Regular" network users rely on network services. System users and groups support those services. 


Some NetWare administrators are concerned about the number of system users and groups on an 
OES Linux server. They wonder what functions system users perform, why there are “so many” of 
them, and how they impact licensing and network security. 


The answers to these and other questions are found in the sections that follow. 


* Section L1.1, “Types of OES System Users and Groups,” on page 263 
¢ Section I.1.2, “OES System Users and Groups by Name,” on page 264 


1.1.1 Types of OES System Users and Groups 


The users and groups that support OES services can be grouped into the three types shown in Table 
I-1. 


Table l-1 Types of System Users and Groups with Examples 


System User or Group Type Purpose Examples 


Proxy User Perform very specific service- * afpProxyUser-servername 


related functions, such as * cifsProxyUser-servername 


* Retrieving passwords and * LUM Proxy user 
service attributes 


* Writing Service information 
in eDirectory. 


* Providing a user ID (uid) 
that the associated service 
daemon uses to run. 
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System User or Group Type 


System Group 


System User 


Purpose 


* Facilitate the management 
of system users 


* Provide access rights to 
service data on the server or 
in the eDirectory tree. 


The daemons associated with the 
respective services run as these 
users. 


Examples 


* DHCP 
* DNSDHCP 


* wwwrun 


* iprint 


1.1.2 OES System Users and Groups by Name 


Table I-2 lists the users and groups that OES services depend on and use. 


Table l-2 System User and Groups Listing 


System User or Group 


AfpProxyUser-servername 


Object Type 


Proxy User 


Associated Service 


AFP 





(Archive Versioning Proxy) 


Proxy User 


The install admin is always assigned. 


Archive and Versioning Services 
































arkuser System User Archive and Versioning Services 
CifsProxyUser-servername Proxy User CIFS 
DHCP LDAP Proxy Proxy User DHCP 
dhcpd System User DHCP 
DHCPGroup System Group DHCP 
DNS Proxy Proxy User DNS 
DNSDHCP-GROUP System Group DNS 
hacluster System User Heartbeat 
iFolderProxy Proxy User iFolder 3 
iprint System User iPrint 
Iprint (POSIX) System Group iPrint 


iprintgrp (eDirectory) 














LUM proxy Proxy User Linux User Management 
(optional) 

named System User DNS 

ncsclient System User NCS 

ncsgroup System Group NCS 

NetStorage Proxy Proxy User NetStorage 
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System User or Group Object Type Associated Service 


























novell_nobody System User CIMOM 

novell_nogroup System Group CIMOM 

novlxregd System User XTier 

novlxsrvd System User XTier 

novlxtier System Group XTier 

server name-SambaProxy Proxy User Samba (Novell) 

server name-W-SambaUserGroup System Group Samba (Novell) 

server nameadmin Proxy User NSS 

WWW System Group Apache 
Tomcat 
QuickFinder 

wwwrun System User Apache 


I.2 Understanding Proxy Users 


The subject of OES proxy users is somewhat complex. Therefore, it's a good idea to understand the 
basics before planning your implementation strategy. 





IMPORTANT: The information in the following sections only answers security questions and 
provides general information. It is not intended to be used for the manual configuration of proxy 
users. 





* Section I.2.1, “What Are Proxy Users?,” on page 265 

* Section L2.2, “Why Are Proxy Users Needed on OES Linux?," on page 266 
¢ Section I.2.3, “Which Services Require Proxy Users and Why?,” on page 266 
* Section L.2.4, “What Rights Do Proxy Users Have?,” on page 267 


1.2.1 What Are Proxy Users? 


As the name implies, proxy users are user objects that perform functions on behalf of OES services. 


Proxy user accounts do not represent people, rather they are eDirectory objects that provide very 
specific and limited functionality to OES services. Generally, this includes only retrieving service- 
related information, such as user passwords and service attributes, but sometimes proxy users also 
write service information in eDirectory. 


Many but not all OES services rely on proxy users to run on Linux (see “Which Services Require 
Proxy Users and Why?" on page 266). Proxy user creation and/or configuration is therefore an 
integral part of configuring OES. 
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None of the OES services require that you specify proxy user information during the OES 
installation, but some, such as DNS/DHCP, AFP, CIFS, and iFolder, give you the option to do so. 
Others, such as NCS and NSS create proxy users without user input, while Archive and Versioning 
Services always uses the install admin as its proxy user. 


1.2.2 Why Are Proxy Users Needed on OES Linux? 


OES Linux provides the Novell services that were previously only available on NetWare. 


To make its services available on Linux, Novell had to accommodate a fundamental difference 
between the way services run on NetWare and the way they run on Linux. 


* NetWare Services: The NetWare operating system and eDirectory are tightly integrated. This 
allows the services (NLMs) on NetWare to assume the identity of a server object in eDirectory, 
thus gaining access to the other objects and information in eDirectory that are needed for the 


services to run. 


* OES Linux Services: eDirectory also runs very well on OES Linux, and it provides the 
infrastructure on which OES services rely, but it is not integrated with the Linux operating 


system. 


On Linux servers there is no concept of a service, such as Apache or iFolder running as a server 
object. Instead, each service runs using a User ID (uid) and a Group ID (gid) that the Linux 


server recognizes as being valid. 


1.2.3 Which Services Require Proxy Users and Why? 


The following services utilize a proxy user. 


Table I-3 Proxy Users Functions Listed by Service 





Associated Service Example Proxy User Name Services That the User Provides 
AFP AfpProxyUser-servername Retrieves passwords for AFP users. 
Archive Versioning admin The service runs as this user. 


The install admin is always 








specified. 
CIFS CifsProxyUser-servername Retrieves passwords for CIFS users. 
DHCP DHCP_LDAP_Proxy This lets the service access DHCP objects in 
eDirectory. 
DNS DNS Proxy This lets the service access DNS objects in 
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eDirectory. 


Associated Service Example Proxy User Name 


iFolder 3 iFolderProxy 


Services That the User Provides 


This Folder proxy user connects to the 
eDirectory server and retrieves the following 
information: 

* modifytimestamp 

* cn 

* mail 

* sn 

* GUID 

* givenName 


* member 





Linux User Management | LUM proxy 


Searches the tree for LUM users. 





NetStorage NetStorage Proxy 


The LDAP Admin user is 
specified by default, but 
another user can be created 
prior to installing and then 
specified. 


Performs LDAP searches for users logging 
into NetStorage. 





NSS server nameadmin 


Samba (Novell) server name-SambaProxy 


Reads user objects and maintains the 
volume, pool, and other storage system 
objects. 


This user performs some of the same 
functions as proxy users do for other 
services. However, unlike other OES services 
that can share proxy users, NSS requires a 
unique proxy user for each server. 


Searches the LDAP tree (eDirectory) for 
Samba users. 


1.2.4 What Rights Do Proxy Users Have? 


Each OES service's YaST installation automatically adds the required rights to the proxy user 


specified for the service. 
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Unless otherwise specified, each of the following users has the standard set of user rights in 
eDirectory: 


* Self: 
Login Script: 
Read Write, Not inheritable 
Print Job Configuration: 
Read Write, Not inheritable 
[All Attribute Rights]: 
Read, Inheritable 
* [Public] 
Message Server: 
Read, Not inheritable 
* [Root] 
Group Membership 
Read, Not inheritable 


Network Address 
Read, Not inheritable 


In addition, each proxy user is granted additional rights as summarized in Table I-4. 
Table I-4 Proxy Users Rights 


Associated Service Example Proxy User Name Default Rights Granted 


AFP AfpProxyUser-servername * The Universal Password policy associated with 
the AFP users grants this proxy user the right 
to retrieve AFP user passwords. 


Archive Versioning Archive Versioning Proxy * This user has Read and Write rights to the 
archived volume. 


CIFS CifsProxyUser-servername * The Universal Password policy associated with 
the CIFS users grants this proxy user the right 
to retrieve CIFS user passwords. 





DHCP DHCP_LDAP_Proxy + No rights are assigned directly, but 
membership in the DHCPGroup, which does 
have assigned rights, provides the rights it 
needs. 





DNS DNS_Proxy + No rights are assigned directly, but 
membership in the DNS-DHCPGroup, which 
does have assigned rights, provides the rights 
it needs. 
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Associated Service Example Proxy User Name 


iFolder 3 iFolderProxy 


Default Rights Granted 


* 


Additional eDirectory rights include: 
[Entry Rights] 
Browse 
LDAP ACL representation: 
l#subtree#iFolderProxy# 
[All Attributes Rights] 
Read, Compare 
LDAP ACL representation: 


3#subtree#iFolderProxy# 





Linux User 
Management 


LUM_proxy 


If created, this proxy user has Search rights on 
Unix Config & Unix Workstation Objects. 





NetStorage NetStorage_Proxy 


* 


Additional eDirectory rights: 
[Entry Rights] 
Browse 
LDAP ACL representation: 
l#subtree#NetStorage Proxy# 
[All Attributes Rights] 
Read, Compare 
LDAP ACL representation: 


3#subtree#NetStorage Proxy# 





NSS server_nameadmin 


Additional eDirectory rights: 


Supervisor right to the container it was created 
in. 





Samba (Novell) server_name-SambaProxy 


* 


The Universal Password policy associated with 
the Samba users grants this proxy user the 
right to retrieve user passwords. 


Additional eDirectory rights: 

Rights to itself — Supervisor attribute right 
Rights to the OU where it is located 

All Attribute rights - Read Write 

Entry rights — Browse Create 


samba* — Create Read Write 
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l.3 Planning Your Proxy Users 


Because of the prominent role played by the proxy users on your OES network, it is important that 
you understand your implementation options and the implications for each option. You can then plan 
an overall proxy user implementation strategy. 

* Section 1.3.1, “About Proxy User Creation,” on page 270 

* Section I.3.2, “Proxy User Impacts on User Connection Licenses,” on page 273 

¢ Section 1.3.3, “Limiting the Number of Proxy Users in Your Tree,” on page 273 


* Section I.3.4, “Proxy Users and Passwords,” on page 275 


1.3.1 About Proxy User Creation 


The first step in planning your proxy user implementation strategy is understanding the do’s and 
don’ts of proxy user creation. 


* “Creation Options” on page 270 
* "Do Not Manually Configure Proxy Users" on page 272 
* "Avoid Assigning an Admin User As a Proxy User" on page 272 


Creation Options 


Table I-2 presents information about the creation options for each OES proxy user. 
Table l-5 Proxy User Creation Options 


Associated Service Default Proxy User Name Creation Information 


AFP AfpProxyUser- By default, the AFP YaST install automatically 


servername 
* Creates a proxy user named afpProxyUser- 


servername in the same context as the server. 


* Creates a Universal Password Policy that you can 
assign to AFP users after the install. 


* Generates a password and stores it in either CASA 
or in an encrypted file on the server, depending on 
which option you select. 


Alternatively, you can modify any of the defaults, 
including the password. Or if you have already created a 
proxy user, you can specify that as well. 


If you access the AFP configuration pages and there are 
no Universal Password Policies in your tree, the install 
reminds you that AFP users must have a policy 
assigned. 





Archive Versioning admin The admin account that installs the server is 
automatically assigned as the Archive and Versioning 
proxy user. This is not configurable. 
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Associated Service Default Proxy User Name 


CIFS 


CifsProxyUser- 
servername 


Creation Information 
By default, the CIFS YaST install automatically 


* Creates a proxy user named cifsProxyUser- 
servername in the same context as the server. 


* Creates a Universal Password Policy that you can 
assign to CIFS users after the install. 


* Generates a password, and stores it in either 
CASA or in an encrypted file on the server, 
depending on which option you select. 


Alternatively, you can modify any of the defaults, 
including the password. Or if you have already created a 
proxy user, you can specify that as well. 


If you access the CIFS configuration pages and there 
are no Universal Password Policies in your tree, the 
install reminds you that CIFS users must have a policy 
assigned. 





DHCP 


Same as install admin 


By default, the admin account that installs the server is 
assigned as the DHCP proxy user. 


If you want to assign an alternate user account, it must 
already exist in the tree and be able to access the 
DHCP server object. 





DNS 


iFolder 3 


Same as install admin 


iFolderProxy 


By default, the admin account that installs the server is 
assigned as the DNS proxy user. 


If you want to assign an alternate user account, it must 
already exist in the tree and have Read, Write, and 
Browse rights in the contexts where the DNS Locator, 
Root Server, and Group Object are created. 


By default, the system automatically creates a proxy 
user named iFolderProxy. 


Alternatively, you can modify any of the defaults, 
including the password, or if you have already created a 
proxy user, you can specify that as well. The user must 
have the Read right to the LDAP service. 





Linux User 
Management 


LUM proxy (optional) 


(Optional) By default, no LUM proxy user is created. If 
you create one, it will be assigned rights to search the 
LDAP tree for LUM objects. If you assign an existing 
user, it must have the aforementioned LDAP search 
rights. 





NetStorage 


Same as install admin 


By default, the admin account that installs the server is 
assigned as the NetStorage proxy user. 


Alternatively, you can specify an existing proxy user with 
rights to search the LDAP tree if desired. 





NSS 


server nameadmin 


This admin account must have full rights to administer 
NSS and must be unique to each server. 
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Associated Service Default Proxy User Name Creation Information 


Samba (Novell) server_name- By default, the Samba proxy user is created in the 
SambaProxy container specified as the Base Context for Samba 
Users and is named servername-sambaProxyUser. 


You specify the password for this user when you 
configure Novell Samba. 


You can specify another eDirectory user as the Samba 
proxy user. If you do, be aware of the following: 


* |f you specify a user that doesn't already exist in 
eDirectory, the user account is created and 
granted the necessary rights. You must also 
specify a password for the new user. 

* |f you specify an existing eDirectory user, it is 
assumed that you have already created the user 
account with the necessary rights and no 
modifications are made to the existing user. 


* |f you specify an existing eDirectory user but enter 
a new password, you are prompted to change the 
password for that user. 


Do Not Manually Configure Proxy Users 


Best practices for most OES installation scenarios dictate that proxy users be created in eDirectory 
prior to installing OES. For more information, see “Limiting the Number of Proxy Users in Your 
Tree" on page 273. 


After creation, proxy users should be configured for OES service use only by the YaST based install, 
not manually. 


The information in these sections only answers security questions and provides general information. 
It is not intended to be used for the manual configuration of proxy users. 


Avoid Assigning an Admin User As a Proxy User 


We recommend using special-purpose proxy user accounts rather than specifying admin users as 
proxy users. 


Although specifying an admin user as the proxy user appears to be an easy way of setting up OES 
services (and is the install default in some cases), there are potential problems. Mixing actual users 
with system-level functionality always creates some risk. 


The following is a real-life example of risks that can occur when admin users are assigned as proxy 
Users: 


Novell Support received a call from an administrator who was getting locked out due to intruder 
detection after changing the administrator password. The lockout happened several times each day 
and seemed to be coming from the OES 2 servers. The support technician checked LUM and all of 
the services he could think of, and didn't see the admin credentials anywhere. 
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Further investigation revealed that the administrator credentials had been used to install OES 2 on 
multiple servers, and by default the credentials were therefore also used as the proxy user credentials 
for some of the OES services. Consequently, the credentials were stored in CASA for use when the 
OES services came up. 


Because the Admin password had changed, the CASA credentials had expired and service 


authentication requests were failing, resulting in the intruder detection lockout. 


1.3.2 Proxy User Impacts on User Connection Licenses 


From a licensing standpoint, each proxy user counts as a user on the OES network and consumes 
one user connection license. 


It is not unreasonable to expect that the OES servers you install could average five to six proxy users 
a piece, meaning that an organization that has three to five OES servers installed with the default 
settings, can expect that 15 to 30 of its user connection licenses might be taken by proxy users. 


For large organizations with hundreds of servers, the user connections consumed by default 
installations would be substantial. Therefore, large organizations are especially interested in 
methods for limiting the number of proxy users on their network. 


1.3.3 Limiting the Number of Proxy Users in Your Tree 


Table I-6 outlines various options for limiting the number of proxy users in your tree and 
summarizes the licensing, security, and manageability considerations of each approach. 


Table l-6 Options for Limiting the Number of Proxy Users 


Approach Licensing Impact Security Considerations Manageability Considerations 


Per Service per One for each For AFP, CIFS, iFolder 3, NSS, This approach requires no proxy 


Server (default) service on each and Samba this is the most user planning. 
server secure option. Passwords for i . 
these are system-generated Services are installed at the same 
and not known by anyone. time as the OES server. 
For LUM there is no option to This is a good option for small 
have a system-generated organizations or installations 
password. where only a few services are 
used. 


For DNS, DHCP, and D. a 
NetStorage, the install admin’s This is not a good option if 
credentials are used by default. security policies dictate that all 
This has separate security passwords must be reset 
implications as outlined in periodically. 

“Avoid Assigning an Admin 

User As a Proxy User” on 

page 272. 
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Approach Licensing Impact Security Considerations 


Per Server One for each This confines any security 
server vulnerabilities to individual 
servers. 


Manageability Considerations 


This requires that a proxy user for 
the server is created before the 
server is installed. 


For the first server in the tree, 
eDirectory and iManager must be 
installed with the server. Then 
after the server installation 
finishes, the proxy user can be 
created. And finally the services 
can be installed and configured to 
use the proxy user for the server. 


This is not generally 
recommended. However, it can be 
useful when each OES server is 
managed by a separate 
administrator, or for enterprises 
where branch users access a 
server in the branch office. 


The install admin must know the 
proxy user’s password. 





Per Partition One for each This confines any security 
partition vulnerabilities to individual 
partitions. 


This is useful when users are co- 
located with the OES servers ina 
single partition, and cross-partition 
access of users to services is rare. 


This is a good approach for 
organizations where eDirectory 
administration is done ata 
partition level. 


This requires that a proxy user for 
the partition is created before 
services are installed in the 
partition. 


The install admin must know the 
proxy user’s password. 





Per Service Up to nine This confines any security 
licenses vulnerabilities to individual 
depending on services. 


the number of 
OES services It also ensures that proxy user 


deployed rights are not overloaded but 
are distributed so that there is a 
single proxy user for each type 
of service 
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For example, you might have one 
proxy user for file-access (AFP, 
CIFS), one for DNS/DHCP, one for 
iFolder, one for iPrint etc. 


This is useful in trees where the 
users and servers are not co- 
located, and different services are 
administered by different 
administrators. 


This requires that a proxy user for 
the service is created before the 
service is installed in the tree. 


The install admin must know the 
proxy user's password. 


Approach Licensing Impact Security Considerations Manageability Considerations 


Per Tree One license This exposes all OES services This requires that a proxy user for 
and servers in the tree to any the tree is created before any 
security vulnerabilities. OES services are installed in the 

tree. 


This is suitable for organizations 
that have 


* Centralized eDirectory 
administration 


* Users that are not confined 
to the partition or subtree 
where the OES servers 
reside, but instead access 
different OES servers from 
all over the tree. 


The install admin must know the 
proxy user's password. 


1.3.4 Proxy Users and Passwords 


Proxy user passwords must be stored on the individual OES servers where the services are installed 
because proxy users must be able to log in to eDirectory to perform their required functions. 

* "Auto-Generated vs. Specified Passwords" on page 275 

* "Passwords Are Stored on the Server" on page 275 


* "Avoid Password Expiration Problems" on page 276 


Auto-Generated vs. Specified Passwords 


* Auto-Generated Passwords: AFP, CIFS, iFolder 3, NSS, and Samba use auto-generated 
passwords by default. 


This offers the highest security because the passwords are known only to the system. However, 
this option generates one proxy user per service per server, and it is critical that the assigned 
password policies not cause passwords to expire. 

* Manually Specified Passwords: For Archive and Versioning, DNS, DHCP, LUM, and 
NetStorage, this is the only available option, and it applies to the other OES services in all but 
the default (per service per server) installation scenario. It requires that someone keep track of 
the proxy user names and passwords for installation purposes. 


Passwords Are Stored on the Server 


Of course all proxy user passwords are stored in eDirectory. Table I-7 explains where they are stored 
on the server and how they can be reset 1f needed. 
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Table l-7 Password Storage Locations 


Associated Service Where the Password Is Stored Locally 


How the Password Can Be Reset 


























AFP This password is stored in either CASA You can use iManager to reset the 
or in an encrypted file, depending on password in CASA or in the encrypted file, 
the configuration option specified or the CASAcli tool if it is stored in CASA. 
during service installation. 

Archive and This password is stored in CASA. You must use the script provided by 

Versioning Archive and Versioning Services to change 

the password on the server. 

CIFS This password is stored in either CASA You can use iManager to reset the 
or in an encrypted file, depending on password in CASA or in the encrypted file, 
the configuration option specified or the CASAcli tool if it is stored in CASA. 
during service installation. 

DHCP This password is stored in CASA if itis If the password is stored in CASA, you can 
available. If CASA is not available, itis set it using the CASAcli tool. If not, edit the 
stored in the /etc/dhcpd.conf file. |. /etc/dhcpd.conf file. 

DNS This password is stored in CASA if itis ?? 
available. If CASA is not available, it is 
stored in an encrypted file. 

iFolder 3 This password is stored in the iFolder It can be changed either from a terminal 
store with PKI cryptography. prompt using the iFolder command line 

utilities or through the iFolder Admin 
Console. 

Linux User This is stored inthe /etc/nam.conf Editthe /etc/nam.conf file and change 

Management file. the password in eDirectory. 

NetStorage This password is stored in the XTier This can be changed in iManager through 
registry. the NetStorage plug-in. 

NSS ?? This password is system-generated at 


install time and cannot be reset. 





Samba (Novell) 


This password is stored in Samba. 


You can change the password by using the 
smbpasswd command. 


IMPORTANT: Although the YaST based install can sometimes be used successfully to reconfigure 
some OES services, Novell neither recommends nor supports that practice. 





Avoid Password Expiration Problems 


Many organizations require that all network users have password policies to enforce regular 
password expiration and change. 


Such policies create complications for the proxy user design. Proxy user passwords are stored on the 
local system to enable the OES services to log in to eDirectory. Every time a password change is 
forced in eDirectory, services stop working until the password is sychronized on the server. 
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These problems can be avoided by: 


+ Not assigning proxy users a password policy that enforces password expiration. 
+ Not using real user credentials for proxy users. See “Avoid Assigning an Admin User As a 
Proxy User" on page 272. 


If password expiration policies cannot be avoided, or a security policy dictates that proxy user 
passwords must be changed periodically, you can do the following. 


* Ensure that the responsible administrator knows or has a record of each proxy user's password 
and is aware of when they expire. 


* Before passwords expire, change them in eDirectory and reset them on the server. See the 
information in Table I-7. 


l.4 Implementing Your Proxy User Plan 


The proxy users in OES can be configured at different levels within eDirectory, depending on your 
needs. 





IMPORTANT: The brief instructions that follow assume that you are installing into an existing 
tree. For new trees you will need to install and configure eDirectory on the first server without 
configuring any other OES services. 


After the server is installed and you have created the required proxy users and passwords, then you 
can install the OES services and configure them to use the proxy users you have created. 


The exception to this is installing all services without changing the default configuration settings 
(see Table I-5 on page 270). In most cases a default configuration assigns the install admin as the 
proxy user for the service. 





1.4.1 Tree-wide proxy users 


Do the following: 


1. Create a proxy user in the eDirectory tree where the OES servers will be installed, and set the 
password. 


Consider naming the user to reflect its purpose. For example, name the proxy user 
Oes service proxy user. 


2. Use this proxy user and password while configuring the services on all of the OES servers in 
that tree. 
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1.4.2 Service-specific proxy users 


Do the following: 
1. Create a proxy user in the eDirectory tree for each type of OES service and set the passwords. 


Consider naming the user to reflect its purpose. For example, name the AFP proxy user, 
afp proxy user. 


2. Use these proxy users and passwords appropriately for each of the OES services on all OES 
servers. 


1.4.3 Partition-wide proxy users 


Do the following: 
1. Create one proxy user object per eDirectory partition in the OES tree, and set the password. 


Consider naming the user to reflect its purpose. For example, name the proxy user for the 
London regional office, london office proxy user. 


2. Use this proxy user and password for configuring all of the OES services on all the OES servers 
in that partition. 


1.4.4 Server-wide proxy user 


Do the following: 


1. Create one proxy user object per OES server (preferably in the same container as the server) 
and set the password 


2. Use this proxy user and password as the proxy user for all the services on that particular OES 
server. 


1.4.5 Individual proxy user per-server-per-service 


This is the installation default as explained in Table 1-6, “Options for Limiting the Number of Proxy 
Users," on page 273. 


I.5 Proxy Users and Domain Services for 
Windows 
Proxy users are not used in DSfW. 


The Services part of the Trusted Computed Base has the rights to read users' supplemental 
credentials for authentication. A separate KRB process reads user passwords and performs the 
authentication. Another event handler in eDirectory creates the supplemental credentials for the user 
whenever the password is changed for that user. 


I.6 System Users 


SLES and OES create system users on the local Linux system to provide user IDs (uids) to service 
processes. These users have rights to local files, such as configuration files. 
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The services that rely on system users do not have passwords because they don’t need to log in. 
They simply use their associated user IDs. 


When NSS is installed, some of these users are moved to eDirectory and LUM enabled. This is done 
to provide access to NSS data, to keep the user IDs the same across multiple servers, and to facilitate 
clustering and shared volumes. 


Table I-2 lists the various system users that are used by OES services. 


Table l-8 System User Purposes 


System User or 


Group Name Associated Service Purpose 


arkuser Archive and The service uses PostgreSQL as its metadata store, and 
Versioning PostgreSQL must run as a low-privileged user. 
Services 


arkuser is that low-privileged user. 


dhcpd DHCP DHCP accesses local resources through this or an alternatively 
specified user. 


If the DHCP lease and configuration files are stored on NSS, the 
user must be moved to eDirectory and LUM enabled. 


dhcpd is used by default, but any local user can be used. 





hacluster Heartbeat This user is created by Heartbeat, but it not used by Heartbeat nor 
by Novell Cluster Services. 





iprint iPrint The iPrint daemons run as this user. 


If iPrint is moved to NSS, this user is created in eDirectory and the 
local user is removed. 





named DNS This system user lets DNS access local resources. 


In case of clusters, DNS data is on NSS volume, and so the user 
has to be created in eDirectory as well. 


named is used by default, but any local user can be used. 











ncsclient NCS Used by NCS to access the adminfs file system. 
novell nobody CIMOM This user is created by CIMOM but is not currently used. 
novixregd XTier The XTier Registry Daemon (novell-xregd) runs as this user. 


When NSS is installed on the Linux server, this user is removed 
from the local system and created as LUM-enabled user in 
eDirectory. This is required because it must have access to NSS 
data, and all NSS access is controlled through eDirectory. 





novixsrvd XTier The XTier Server Daemon (novell-xsrvd) runs as this user. 


When NSS is installed on the Linux server, this user is removed 
from the local system and created as LUM-enabled user in 
eDirectory. This is required because it must have access to NSS 
data, and all NSS access is controlled through eDirectory. 
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System User or 


Group Name Associated Service Purpose 


wwwrun Apache The Apache daemon runs as this user. 


When NSS is installed on the Linux server, this user is removed 
from the local system and created as LUM-enabled user in 
eDirectory. This is required because it must have access to NSS 
data, and all NSS access is controlled through eDirectory. 


l.7 System Groups 


These are groups in the local Linux system that provide a group ID (gid) to an OES process. 


When NSS is installed, some of these groups are moved to eDirectory and LUM enabled. This is 
done to provide access to NSS data and to keep group IDs the same across multiple servers. 


Table I-2 lists the system groups that are used by OES services. 


Table l-9 System Group Purposes 


System User or Group Name Associated Service 


DHCPGroup DHCP 


DNSDHCP-GROUP DNS 


Purpose 


The DNS and DHCP servers and proxy users gain 
rights to DHCP data within the tree through this 
Group Object 


Linux DNS Servers gain rights to DNS data within the 
tree through this Group object. (The name reflects the 
fact that this group was used on NetWare for both 
DHCP and DNS.) 





Iprint (POSIX) iPrint 


iprintgrp (eDirectory) 


The iPrint daemons use the group ID (gid) of this 
group to run. 


If iPrint is moved to NSS, the iprintgrp group is 
created in eDirectory. 











ncsgroup NCS ncsclient is a member of this group. 

novell nogroup CIMOM This group is created by CIMOM but is not currently 
used. 

novixtier XTier The XTier daemons use the group id (gid) of this 
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group to run. 


Apache (wwwrun) is a group member because it 
needs XTier socket access. 


When NSS is installed on the Linux server, this group 
is removed from the local system and created in 
eDirectory. This is required because members of this 
group must have access to NSS data, and all NSS 
access is controlled through eDirectory. 


System User or Group Name Associated Service 


server_name-W- 


Samba (Novell) 


Purpose 


All users granted Samba access are originally 








SambaUserGroup assigned to this group, which disables SSH access 
for them on the server. For more information, see 
"The Samba connection:” on page 98. 
shadow QuickFinder Used by QuickFinder and other Web services. 
WWW Apache Apache (wwwrun) and tomcat (novlwww) use the 
group ID (gid) of this group to run. 
Tomcat 
QuickFinder requires that all users who manage the 
QuickFinder 


service (including the eDirectory Admin user) belong 
to this group. 


User novlxsrvd is in the group because it needs 
access to an Apache domain socket. 


When NSS is installed on the Linux server, this group 
is removed from the local system and created in 
eDirectory. This is required because members of this 
group must have access to NSS data, and all NSS 
access is controlled through eDirectory. 
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Administrative Users in OES 2 SP1 


Every OES network requires at least one administrative-level user to manage regular network users 
and system users. 


Table J-1 Administrative Users and Groups 


Administrative User or 


Group Associated Service Object Type Purpose 


Admin eDirectory Admin User The eDirectory administrator that 
has all rights to manage the Tree. 
The default is Admin. 





Container Admin eDirectory Admin User These administrators are usually 
responsible for administering 
within a partition or subtree. 


They might be assigned only 
enough rights to install servers, or 
they might be assigned to specific 
roles in iManager. 





admingroup eDirectory Admin Group Provides LUM-enabling for the 
eDirectory administrator. 





iFolderAdmin iFolder 3 Service Admin This is the default iFolder service 
administrator account. By default, 
the Tree Admin is specified. 





QuickFinderAdmin QuickFinder Service Admin This is the QuickFinder 
administrator. 


The default is the Tree Admin. 
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Documentation Updates 


This section summarizes the changes made to this manual since the initial release of Novell® Open 


Enterprise Server 2 SP1. 


October 14, 2009 


Chapter or Section Changed 
“SLES Licensing Entitlements in OES 2" 
on page 54. 


July 31, 2009 


Chapter or Section Changed 


“System User and Group Management in 
OES 2 SP1” on page 263. 


Summary of Changes 


New section added to draw attention to the SLES 
entitlement change made September 1, 2009. 


Summary of Changes 


Completely reworked and expanded Section. 





“Administrative Users in OES 2 SP1” on 
page 283. 


June 22, 2009 


Chapter or Section Changed 


“Avoid Uninstalling eDirectory” on page 62. 


New Section. 


Summary of Changes 


New Section. 





“Web Services” on page 67. 


May 6, 2009 


Chapter or Section Changed 


“SLP” on page 116. 


New Section. 


Summary of Changes 


Removed all information and instructions that refer to 
incompatibilities between Novell SLP and OpenSLP. This 
information was outdated. 


Although there are differences in the two SLP services (see 
Table 12-4 on page 117), they are completely compatible 
regarding the sharing of service information. 
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May 4, 2009 


Chapter or Section Changed 


“Changing the Server’s Address 
Configuration” on page 244. 


April 23, 2009 


Chapter or Section Changed 


“What's New” on page 15. 


April 7, 2009 


Chapter or Section Changed 


Throughout the guide. 


Summary of Changes 


In response to a user comment, correct link to wrong file. 


Summary of Changes 


In response to a user comment, reorganized section for 
clarity. 


Summary of Changes 


General editing changes. Nothing substantive. 
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